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I.  MANAGEMENT  INFORMATION  SYSTEMS 


AND  DISTRIBUTED  PROCESSING 

A.  MANAGEMENT  INFORMATION  SYSTEMS 

Managers  must  have  complete,  accurate,  and  timely  information 
available  in  order  to  make  sound  business  decisions.  A  schematic  model 
of  the  relationship  between  an  information  system  for  managers,  a 
management  information  system,  and  a  production  system  is  shown  in 
figure  1.  As  demonstrated  by  this  model,  the  management  information 
system  measures  attributes  of  the  production  system,  processes  the  data, 
and  prepares  management  information  reports.  In  reality,  the  manage¬ 
ment  information  system  is  a  part  of  the  control  loop  that  maintains 
dynamic  control  over  the  enterprise.  The  purpose  of  this  section  is 
threefold:  to  provide  a  working  definition  of  a  management  information 
system;  to  delineate  its  general  characteristics;  and,  to  list  common 
objectives  of  management  information  systems. 

1 .  Significance  of  a  Management  Information  System 

Every  business  enterprise  has  a  management  information  system 
(MIS),  however  simple  it  may  be.  In  a  two-man  partnership  in  which  one 
man  handles  production  and  the  other  handles  sales,  each  informs  the 
other  of  developments  affecting  his  own  area  of  the  operation.  Thus, 
the  firm  has  an  adequate  MIS,  even  if  the  primary  vehicle  is  oral 
communication.  In  a  slightly  larger  enterprise,  the  management  infor¬ 
mation  system  may  consist  of  manually  prepared  records  and  reports  used 
to  control  and  plan  the  business.  The  next  level  is  the  use  of  basic 
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Figure  1  INFORMAT  ION/PRODUCT ION  SYSTEM  RELATIONSHIP 
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mechanical  equipment  to  lessen  the  record-keeping  burden  and  to  increase 
its  effectiveness.  This  equipment  may  include  bookkeeping  machines, 
calculators,  and  accounting  machines.  Larger  companies  require  a 
higher  level  of  both  equipment  and  procedural  sophistication.  These 
companies  may  have  a  very  large  computer  processor  connected  to  remote 
field  offices,  plants,  and  headquarters  by  high-speed  teleprocessing 
equipment.  The  computer  complex  may  record  business  transactions  as 
they  take  place,  analyze  them,  feed  required  support  information  to  all 
related  areas,  and  service  inquiry  activity  concerning  all  of  the 
stored  transactions.  At  this  end  of  the  MIS  spectrum,  the  operation  is 
expensive,  involving  an  annual  monetary  outlay  in  the  mil  1 ion-dollar 
cost  bracket.  The  tailoring  of  the  system  to  the  user's  real  needs 
becomes  a  critical  and  complex  task.  Meeting  the  information  needs  of 
management  with  a  poorly  conceived  system  which  is  either  too  weak  for 
proper  response,  or  too  powerful,  and  thus  too  costly,  can  lead  to 
disaster  for  the  user.  Additionally,  the  use  of  an  advanced  information 
system  may  determine  management’s  ability  to  survive  in  a  growth  environ¬ 
ment.  An  effective  MIS  is  critical  to  all  business  enterprises.  With¬ 
out  it,  growth  is  inhibited,  and  paper  work  may  very  well  strangle  the 
enterprise. 

2.  MIS  Defined 

In  most  discussion  articles,  books,  seminars,  and  even  univer¬ 
sity  courses  concerned  with  management  information  systems,  there  is  an 
initial  difficulty  in  proceeding  to  the  components  of  an  MIS  because 
there  is  considerable  controversy  as  to  the  definition  of  a  management 
information  system.  Sherman  Blumenthal  has  created  a  sixteen-part 
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definition  of  a  mangement  information  system  [1]  in  which  a  primitive 
concept  (such  as:  "datum  -  an  uninterpreted  raw  statement  of  fact”) 
is  defined,  and  progressively  more  complex  concepts  are  explained  in 
terms  of  the  simpler,  previously  clarified  ones  until  a  management 
information  system  is  ultimately  defined  as  consisting  of  parts  of 
operational  functions:  "A  management  information  system  is  an  opera¬ 
tional  function  whose  parts,  corresponding  to  functional  units,  are 
information  subsystems  of  other  operational  functions."  A  management 
information  system  becomes  alternately  definable  as  an  operational 
function  whose  parts  are  the  management  control  modules  (that  part  of 
the  information  subsystem  which  supports  the  management  control  centers 
of  an  operational  function)  and  operational  control  modules  (that  part 
of  an  information  subsystem  supporting  functional  units  of  an  opera¬ 
tional  function)  of  other  operational  functions.  This  rather  imposing 
synopsis  is  neither  meaningful  nor  universally  applicable. 

The  Instruction  which  promulgates  the  instructions  and  proce¬ 
dures  for  the  operation  and  control  of  the  Shipyard  Management  Informa¬ 
tion  System  at  Mare  Island  Naval  Shipyard,  NAVSHIPYDMAREINST  5260. IB 
of  2  November  1978  [2],  specifically  defines  a  management  information 
system  as: 

The  combination  of  personnel  efforts,  forms,  formats, 
instructions,  procedures,  data,  information  and  communi¬ 
cation  facilities  related  to  automatic  data  processing 
equipment  which  providesan  organized  and  interconnected 
means  (either  automated,  manual,  or  a  combination  of 
these)  for  recording,  collecting,  transmitting,  proces¬ 
sing,  and  displaying  information  in  support  of  the 
functions  of  planning,  directing  and  controlling  the 
management  of  an  activity  as  performed  by  an  operational 
level  therein. 
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This  definition,  while  certainly  specific  enough  for  the  management 
information  system  at  Mare  Island  Naval  Shipyard,  cannot  be  universally 
applied  because  it  is  too  restrictive. 

After  analyzing  numerous  descriptions,  applications,  character¬ 
istics,  and  attributes  of  management  information  system  definitions, 
the  following  synthesis,  as  proposed  by  Walter  Kennevan  [3],  shall 
serve  as  the  basic  definition  of  an  MIS  for  this  presentation: 

A  management  information  system  is  an  organized  method  of 
providing  past,  present  and  projection  information  relating 
to  internal  operations  and  external  intelligence.  It  supports 
the  planning,  control  and  operational  functions  of  an  organi¬ 
zation  by  furnishing  uniform  information  in  the  proper  time- 
frame  to  assist  the  decision-making  process. 

This  proposed  definition  of  management  information  can  be  applied 

whether  the  underlying  data  are  compiled,  processed  and  disseminated 

by  manual,  mechanical,  electro-mechanical  or  electronic  methods.  It 

is  also  applicable  to  all  systems  ranging  from  the  least  abstract  to 

those  which  utilize  the  most  sophisticated  mathematical  techniques. 

3.  MIS  Characteristics 

This  definition  of  a  MIS  leads  to  the  ten  basic  detailed  chara¬ 
cteristics  inherent  in  a  management  information  system.  These  dis¬ 
tinguishing  characteristics  are  that  the  system:  (1)  considers  the 
full  effect  of  a  decision  in  advance  by  supplying  complete,  accurate, 
and  timely  data  for  use  in  the  planning  and  decision-making  processes; 
(2)  eliminates  from  the  planning  and  decision-making  processes  the 
problems  associated  with  the  use  of  inconsistent  and  incomplete  data 
by  providing  a  means  for  preparing  and  presenting  information  in  a  uni¬ 
form  manner;  (3)  uses  common  data  and  methods  in  the  preparation  of 
long-range  and  short-term  plans;  (4)  identifies,  structures,  and 
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quantifies  significant  past  relationships,  and  forecasts  future  rela¬ 
tionships  through  the  use  of  advanced  mathematical  techniques  in  analy¬ 
zing  data,  wherever  it  is  appropriate  to  do  so. 

Furthermore,  the  system  must:  (5)  merge  financial  and  pro¬ 
duction  data,  and  all  other  pertinent  data,  to  produce  significant 
measures  of  performance  to  facilitate  control  of  present  costs,  and  to 
facilitate  planning  decisions  with  a  minimum  of  data  processing  by 
utilizing  standard  data  elements;  (6)  recognize  the  needs  of  all  func¬ 
tional  units  so  that  the  requirements  of  each  are  met  with  a  minimum  of 
duplication  while  serving  the  corporation  as  a  whole;  (7)  reduce  the 
time  and  volume  of  information  required  to  make  decisions  by  reporting 
to  each  level  of  management  only  necessary  detail,  and  usually  only  the 
exception  form  the  standard  or  norm;  (8)  utilize  personnel  and  data 
processing  equipment  effectively  so  that  the  optimum  in  speed  and  accur¬ 
acy  is  achieved  at  the  lowest  possible  cost;  (9)  require  that  the 
resulting  information  be  presented  to  those  responsible  for  the  deci¬ 
sion-making  and  planning  processes  in  a  form  which  minimizes  the  need 
for  analysis  and  interpretation;  and  (10),  provide  for  system  flexi¬ 
bility  and  adaptability  to  change. 

4.  MIS  Objectives 

In  order  to  adequately  specify  the  objectives  of  a  management 
information  system,  the  structure  of  an  organization  must  itself  be 
understood.  This  structure  cannot  be  viewed  as  a  static  organization 
that  is  divided  into  divisions  and  departments,  but  as  a  dynamic, 
adaptable  system.  Within  the  organization,  many  processes  take  place 
in  reaction  to  the  present  environment  and  in  anticipation  of  the  future 
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environment.  These  processes  and  flows,  the  resources  needed  to  exe¬ 
cute  them,  and  the  distribution  of  managerial  responsibilities  needed 
to  accomplish  the  required  functions  must  be  understood.  Knowing 
these  major  forces  affecting  the  nature  of  an  organizational  system 
enables  one  to  translate  the  objectives  of  the  entire  organizational 
system  into  the  MIS  objectives  to  serve  that  organizational  system. 

Since  it  is  true  that  objectives  of  different  types  of  organi¬ 
zations  are  normally  different,  it  can  be  assumed  that  MIS  objectives 
of  these  different  types  of  organizations  are  also  probably  different. 
However,  a  common  link  for  the  management  information  systems  of  all 
types  of  organizations  has  been  established  as  described  by  the  seven 
general  objectives  delineated  below  [4].  For  a  specific  organization, 
these  general  objectives  may  require  modification  in  order  to  make  them 
suitable  to  the  needs  of  the  specific  organizational  system  concerned. 

The  general  MIS  objectives  are:  integration  of  the  six  levels  of  a 
MIS;  support  of  strategic  organizational  objectives;  maintaining  the 
primacy  of  managerial  decisions  over  machine  decisions;  the  automation 
of  repetitive  control  functions;  the  streamlining  of  the  adaptability 
process;  keeping  the  management  information  system  adaptable;  and, 
keeping  the  MIS  cost-effective. 

a.  Integrate  the  Six  MIS  Levels 

The  six  levels  of  a  MIS  and  the  operational  personnel  asso¬ 
ciated  with  each  level,  as  presented  in  figure  2,  are:  the  four  user 
oriented  levels  of  planning  (planners),  control  (supervisors),  fore¬ 
casting  (forecasters),  and  modeling  (modelers);  and  the  two  technological 
levels  of  computing  (computer  specialists),  and  data  administration  (data 
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Figure  2 


SIX  LEVELS  OF  MIS 
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administrators).  The  managers,  management  specialists,  and  information 
specialists  within  these  levels  each  employ  different  jargons,  techni¬ 
ques,  and  data  in  the  pursuit  of  their  goals.  Proper  integration  of  an 
organization  through  the  management  information  system  allows  each  of 
these  areas  to  interact  with  the  system  in  its  own  terms,  and  to  accom¬ 
plish  its  job  in  the  most  expeditious  manner.  At  the  same  time,  the 
MIS  acts  as  a  catalyst  among  these  people  of  diverse  skills,  and  enables 
them  to  work  on  a  common  project. 

b.  Support  Strategic  Organizational  Objectives 

Strategic  objectives  of  an  organization  delineate  expected 
achievements  over  a  period  of  time.  Strategic  objectives  become  guide¬ 
lines  for  the  development  of  plans  for  future  operations.  Strategic 
objectives  are  also  guidelines  for  the  tools  requited  for  the  develop¬ 
ment,  implementation,  and  assessment  of  plans.  The  MIS  which  is  planned 
with  the  objective  of  supporting  the  strategic  objectives  of  the  organi¬ 
zation,  will  contain  data  that  assists  in  the  determination  of  specific 
types  of  problem  areas  and  contain  models  that  are  appropriate  to  the 
forecasts  and  plans  under  development.  The  MIS  will  aggregate  data  in 
a  manner  allowing  the  planner,  supervisor,  forecaster,  and  modeler  to 
do  their  best  toward  reaching  the  strategic  objectives  of  the  organi¬ 
zational  system. 

c.  Maintain  Primacy  of  Managerial  Decisions 

The  purpose  of  any  information  system  is  to  supply  informa¬ 
tion  to  people  so  that  they  can  make  appropriate  decisions  based  on 
information  that  is  both  timely  and  relevant.  This  implies  that  the 
primary  job  of  a  management  information  system  is  to  aid  people  in  the 
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solution  of  nonstructured  problems  which  occur  in  the  development  of 
models  that  are  essentially  hypotheses  about  the  organizational  system 
to  be  tested  and  improved  so  that  they  eventually,  within  reason, 
resemble  the  actual  nature  of  the  organizational  system.  Nonstruc¬ 
tured  problems  occur  in  planning,  where  problem  areas  must  be  recognized, 
assumptions  made,  criteria  defined,  and  alternatives  evaluated.  In  the 
nonstructured  problems,  it  becomes  obvious  that  man  must  make  decisions 
using  the  machine  as  his  tool.  The  machine  will  do  the  tedious  work  of 
data  searching,  calculating,  summarizing  and  comparing.  Man,  on  the 
other  hand,  must  do  the  creative  work:  deciding  on  a  course  of  action, 
guiding  the  machine  in  its  work,  and  evaluating  the  results  produced  by 
the  machine.  Thus,  the  manager  makes  the  decisions,  not  the  machine. 

d.  Automate  Repetitive  Control  Functions 

The  MIS  aids  management  in  the  solution  of  nonstructured 
problems  by  removing  from  the  manager's  concern  much  of  the  repetitive 
control  functions.  Since  many  control  functions  are  highly  structured, 
they  are  easily  automated.  This  objective  may  appear  to  be  contradictory 
to  the  previous  objective  -  maintain  primacy  of  management  decisions 
over  machine  decisions.  However,  this  is  not  so  in  that  the  intent  of 
this  objective  is  to  automate  the  maintenance  of  the  database  and  the 
comparisons  of  achieved  status  versus  planned  status,  and  to  produce 
associated  outputs.  Decisions  are  not  made  by  the  machine,  but  by  super¬ 
visory  personnel  who  study  these  outputs. 

e.  Streamline  the  Adaptability  Process 

Adaptability  is  a  very  important  characteristic  of  any 
enterprise.  The  organization  must  be  able  to  recognize  and  react 
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rapidly  to  changes  in  technological  and  customer  requirements.  The 
management  information  system  is  able  to  streamline  this  adaptability 
process  by  employing  three  major  practices:  maintain  extensive  data 
about  external  factors  which  have  historically  affected  the  organiza¬ 
tion,  and  develop  techniques  which  help  identify  new  trends;  maintain 
the  control  system  in  order  to  be  able  to  ise  it  for  comparison,  but 
allow  a  planner  to  insert  new  goals  with  which  to  compare  actual 
results;  and,  allow  a  manager  to  modify  any  model  to  include  new  fac- 
tors  and  then  gather  data  to  test  that  model. 

f.  Keep  the  MIS  Adaptable 

One  of  the  best  ways  of  enhancing  organizational  adapt¬ 
ability  is  to  make  the  MIS  itself  adaptable.  Although  adaptable  sys¬ 
tems  do  cost  more  to  initially  develop,  design  and  install,  the 'adapt¬ 
able  system  will  not  have  to  be  redeveloped,  redesigned  or  reinstalled. 
Future  changes  are  relatively  easily  accomplished  at  a  relatively  small 
cost.  Some  of  the  capabilities  for  change  that  are  included  in  the 
typical  management  information  system  are:  changing  of  reports  or 
reporting  formats;  changing  methods  of  data  entry  or  data  base  updating; 
modifying  specific  programs  or  models;  increasing  of  storage  capability 
by  adding  additional  storage  devices  of  higher  capacity  and/or  speed, 
or  replacement  of  present  storage  devices  with  newer  ones  of  higher 
capacity  and/or  speed;  and  adding  terminals  to  increase  the  number  of 
time-sharing  stations. 

g.  Keep  the  MIS  Cost-Effective 

The  objective  of  MIS  cost-effectiveness  is  to  obtain  the 
most  effective  system  for  the  money  spent.  This  can  be  done  when  all 
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other  objectives  of  the  organization  are  described  ’ n  meticulous  detail. 
Not  only  must  organizational  objectives  be  delineated,  but  the  relation¬ 
ships  between  the  HIS  and  organizational  objectives  must  be  clearly 
defined  and  thoroughly  analyzed.  An  important  result  of  this  analysis 
is  putting  MIS  objectives  in  priority  order.  Priority  is  determined 
primarily  by  the  importance  of  the  MIS  objectives  that  support  the 
objectives  of  the  total  enterprise.  MIS  objectives  that  support  the 
highest  priority  organizational  objectives  are  thus  found  at  the  top 
of  the  objectives  list,  and  the  lowest  supportive  objectives  at  the 
bottom.  With  such  a  priority  analysis,  the  cost-effectiveness  objec¬ 
tives  are  determined,  and  the  management  information  system  can  be 
acquired  that  best  satisfies  them. 

B.  DISTRIBUTED  PROCESSING 

An  objective  of  distributed  processing  systems  is  to  reduce  large 
data  input  bottlenecks  as  well  as  provide  feedback  of  data  necessary  to 
run  the  enterprise.  Distributed  processing  arose  out  of  the  need  to 
get  computer  power  where  it  is  often  needed  -  at  the  local  level  A 
distributed  processing  approach  gives  local  managers  more  control  over 
and  involvement  with  their  computerized  information  systems  and  removes 
some  of  the  processing  burden  from  the  central  computing  facility.  A 
representative  diagram  of  a  distributed  processing  system  is  presented 
in  figure  3.  The  purpose  of  this  section  is  to  present  the  motivations 
for,  and  the  characteristics  of,  distributed  processing  as  they  apply 
to  management  information  systems. 

1.  Evolution 

Prior  to  the  advent  of  real-time  management  information  systems. 
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information  systems  emphasized  historical  data.  These  systems  concen¬ 
trated  on  producing  historic  types  of  reports  based  upon  today's  defi¬ 
nition  of  yesterday's  requirement.  There  was  very  little  thought  given 
to  the  production  of  relevant  information  for  the  control  of  concurrent 
operations  or  for  future  predictions  of  operating  conditions.  These 
systems  were  oriented  toward  custodial  accounting,  responsibility 
reporting,  integrated  data  processing,  and  integrated  management  infor¬ 
mation  systems  [5]. 

« 

Custodial  accounting  did  not  take  into  consideration  a  basic 
need  of  management  -  that  of  feedback  to  compare  actual  performance  with 
the  desired  standard.  Manual  methods  of  bookkeeping  along  with  punch 
cards  were  utilized  to  process  data  in  a  batch  system.  No  attempt  was 
made  to  integrate  records.  Historical  reports  required  lengthy  proces¬ 
sing  time.  Access  of  files  was  on  a  sequential  basis.  Data  was  pri¬ 
marily  used  for  accounting  purposes  with  output  oriented  information 
processing.  In  summary,  a  custodial  accounting  system  performed  its 
function  slowly  and  with  no  great  concern  for  the  ability  of  data  proces 
sing  to  aid  in  the  decision-making  process. 

The  preparation  of  reports  on  the  basis  of  responsibility  assign 
ments  evolved  from  the  simple  custodial  accounting  approach.  The 
responsibility  reporting  system's  orientation  was  toward  the  accumula¬ 
tion  of  historical  data  for  a  specified  time  period  according  to  proce¬ 
dures  determined  by  the  various  activities  and  levels  of  responsibility 
within  an  organization.  It  was  concerned  with  activities  that  were 
directly  controllable  and  accountable  by  a  particular  individual. 
Although  this  system  made  historical  reports  available  more  rapidly  than 
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did  the  custodial  accounting  system,  problems  still  occurred  in  that 
the  responsibility  accounting  system  was  narrow  in  its  perspective. 

It  failed  to  take  into  consideration  other  subsystems  within  the 
sphere  of  the  organization  -  the  integration  of  personnel,  production, 
sales,  and  inventory,  with  accounting. 

The  result  of  systems  designers  recognizing  that  there  were 
more  facets  to  an  operation  than  just  accounting,  resulted  in  a  logic¬ 
ally  unified  system  known  as  an  integrated  processing  system.  Data 
that  was  entered  into  this  system  was  entered  singly,  as  before,  but 
now  became  available  for  a  multiplicity  of  uses  which  transcended 
organizational  and  functional  boundaries.  Elements  within  a  processing 
activity  that  were  related  to  other  uses  were  combined  into  common 
coordinated  procedures  which  were  made  possible  by  having  the  whole 
system  interrelated.  This  integrated  system  was  also  flexible  since 
the  data  controlling  programs  could  usually  be  readily  changed  as 
opposed  to  retraining  personnel  in  the  use  of  new  equipment  and  proce¬ 
dures.  Although  integration  substantially  reduced  file  duplication 
and  allowed  for  the  coordination  of  major  functions  with  one  another, 
optimum  results  were  still  not  guaranteed.  Control  of  current  opera¬ 
tions  and  the  facilities  of  managerial  functions,  through  a  better 
reporting  system,  was  needed. 

An  integrated  management  information  system  improved  upon 
several  of  the  deficiencies  of  the  integrated  data  processing  system 
by  revising  its  basic  concepts.  This  basic  design  provided  for  decision- 
oriented  information  to  management  that  was  utilized  to  assist  in  the 
planning,  controlling,  and  evaluating  of  the  activities  of  the 
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organization.  Periodic  reports  became  a  secondary  feature;  information 
was  used  more  for  organizational  control  and  it  served  several  uses  and 
ultimately  reduced  costs  of  obtaining  essential  reports.  This  integra¬ 
ted  management  system  provided  more  than  a  mechanical  link  between 
various  organizational  functions;  it  provided  an  automatic  means  of 
performing  routine  decision-making  tasks,  thus  freeing  management  to 
perform  more  complex  tasks  requiring  human  thought  processes.  One 
important  deficiency  of  the  integrated  management  system,  however,  was 
that  data  had  to  be  accumulated  for  a  period  of  time  before  it  could  be 
processed.  For  this  reason,  all  heretofore  mentioned  systems  -  custo¬ 
dial  accounting,  responsibility  reporting,  integrated  data  processing, 
and  integrated  management  information  systems  -  are  termed  backward¬ 
looking  systems,  since  they  observe  past  history  before  generating 
reports  for  feedback.  A  system  that  is  oriented  toward  the  present, 
and  even  the  future,  was  needed  -  a  forward-looking  control  system. 

A  trend  in  information  systems  is  the  implementation  of  real¬ 
time  information  systems,  often  referred  to  as  on-line  real-time 
systems.  Typical  applications  include  hotel  and  airline  reservations, 
stock  market  information,  law  enforcement  intelligence,  and  hospital 
patient  records.  The  overriding  characteristic  of  this  type  of  system 
is  the  on-line  real-time  concept  in  which  data  is  sent  directly  into  the 
computer  for  processing  as  soon  as  it  is  made  available.  The  real¬ 
time  aspect  indicates  that  the  data  is  processed  into  information  and 
returned  to  the  source,  or  some  sort  of  an  action  station,  sufficiently 
soon  m  order  to  effectively  perform  a  controlling  operation  on  the 
environment.  In  order  to  be  effective,  the  real-time  system  must  have 


an  integrated  structure  with  a  data  oriented,  as  opposed  to  a  functional 
or  output  oriented,  data  base  since  data  acquired  from  one  source  will 
serve  more  than  one  functional  area  within  the  organization.  The  data 
base,  then  needs  to  be  structured  in  order  to  satisfy  the  needs  of 
management,  contain  fully  identified  elements  in  order  to  serve  a  vari¬ 
ety  of  purposes  without  an  excessive  amount  of  programming.  One  defi¬ 
ciency  of  a  real-time  system  is  its  inability  to  provide  the  information 
desired  by  the  top-level  executives  who  are  responsible  and  accountable 
for  the  full  range  of  all  of  the  organization's  activities.  Their 
principle  task  revolves  around  strategic  planning  activities.  A 
real-time  information  system  cannot  provide  long-range  information 
as  such.  It  can,  however,  respond  with  immediate  feedback  on  present 
operations,  which  is  necessary  in  order  to  modify  plans.  A  more  recent 
approach  to  real-time  systems  is  distributed  processing. 

2.  Motivations  for  Distributed  Processing 

In  the  evolutionary  cycle  of  computing  systems,  there  has  been 
a  tremendous  dependency  on  one  or  more  large  central  processing  units 
to  perform  the  variety  of  required  data  processing  functions.  Bottle¬ 
necks  are  created  whenever  large  amounts  of  data  are  simultaneously 
presented  to  the  same  processing  unit  with  resulting  undue  delays  in 
information  retrieval.  Distributed  processing  was  formulated  as  an 
antidote  to  that  problem  in  that  it  has  been  postulated  as  being  capable 
of  focusing  computing  power  to  the  location  where  it  was  most  needed, 
at  the  lower  levels  of  the  organization.  This  leads  to  a  system  of 
decentralized  executive  control.  This  decentral ized  control  allows  for 
the  positive  influence  of  the  systems  design  aspects  of  extensibility. 
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integrity,  performance  [6],  and  cost  as  motivational  objectives  for 
implementing  a  distributive  processing  scheme. 

a.  Extensibility 

Extensibility  is  the  degree  to  which  a  system's  functions 
and  performance  can  be  altered  without  changing  the  system  itself. 
Extensibility  is  also  known  by  its  synonyms  of  expandibi lity,  flexi¬ 
bility,  and  adaptability.  Major  benefits  of  extensibility  ere  ease  of 
modification  and  ease  of  growth. 

In  the  sense  of  modification,  extensibility  refers  to  the 
ease  of  the  replacement  of  a  logical  software  function,  or  a  hardware 
element  without  disturbing  its  relationships  with  other  elements. 

Growth  extensibility  allows  for  low  cost  configurations,  upgrading  of 
functions  and  performance  in  small  increments,  and  low  corresponding 
incremental  cost  increase. 

The  decentralized  distributed  system  offers  these  improve¬ 
ments  in  extensibility  over  other  systems  since  boundaries  to  perform¬ 
ance  conditions  are  less  likely,  or  at  least  less  restrictive,  than  for 
centralized  systems.  It  will  thus  be  possible  to  specify  a  minimum  and 
a  maximum  system  size  in  conjunction  with  the  number  of  permitted 
increments  in  order  to  achieve  whatever  performance  level  is  desired. 
These  increments  may  very  well  be  incorporated  without  any  changes  in 
the  hardware  or  software  design  -  especially  if  they  are  prediced,  and 
allowances  made  for  them,  in  initial  system  design. 

b.  Integrity 

The  degree  to  which  a  system  is  able  to  tolerate  faults, 
errors,  and  failures  is  known  as  its  integrity.  Integrity  is  also  known 
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as  fault  tolerance,  and  reliability.  A  fault  is  an  error  generating 
defect  in  system  mechanics  or  algorithms.  Errors  occur  when  good  items 
of  information  are  turned  into  failures  by  the  normal  algorithms  of  the 
system.  A  failure  is  an  event  at  which  the  system  violates  its  speci¬ 
fications.  The  integrity  function  involves  isolation,  diagnosis,  and 
resource  recovery  techniques  which  are  designed  to  prevent  further 
damage  and  restore  the  system  to  a  satisfactory  operating  status. 

Network  resource  sharing  of  a  distributed  processing  system 
accomplishes  the  majority  of  integrity  considerations.  Decentralization 
of  control  also  allows  for  fewer  error-producing  binding  situations 
between  processes  and  individual  processing  elements  such  as  processors, 
memory  and  communication  paths.  Much  interprocess  communication  becomes 
interprocessor  communication  as  a  result  of  decentralized  control,  this 
is  beneficial  from  an  integrity  viewpoint  in  that  detection  and  diagnosis 
is  enhanced  by  the  mutual  cooperation  of  multiple  processors  enabling 
even  difficult  to  discover  errors  of  algorithm  design  to  become  more 
visible. 

c.  Performance 

The  most  prevalent  definition  of  performance  is  throughput 
or  response  time.  A  decrease  in  response  time  is  experienced  under 
centralized  control  when  more  processors  are  added  to  the  system,  so 
that  an  idle  processor  can  immediately  be  activated  to  service  a  request 
without  suspending  other  processing  or  having  the  request  lounge  in  a 
queue  waiting  for  service.  Even  greater  benefits  can  be  derived  when 
many  processors  cooperate  in  a  single  job. 
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d.  Cost-Effective 

Having  several  interconnected  processors  cooperating  on  one 
job  is  also  more  cost-effecti ve  than  the  utilization  of  one  large  proces¬ 
sor  of  equivalent  performance.  The  quantity  and  functionality  of  the 
total  smaller  processor's  logic  systems  is  more  readily  agreeable  to 
high  levels  of  hardware  unity  than  is  that  of  the  larger  processor.  The 
latest,  most  cost-effective  technology  can  be  employed  in  designing  and 
implementing  the  smaller  processors  at  a  relatively  rapid  rate  enabling 
them  to  begin  functioning  sooner  than  their  larger  counterparts.  Since 
smaller  processors  are  manufactured  in  larger  quantities,  they  can  bene¬ 
fit  from  production  economies. 

3.  Characteristics  of  Distributed  Processing 

With  an  understanding  of  the  need  for  and  the  motivational 
factors  concerning  distributed  processing,  several  characteristics 
that  delineate  a  system  as  being  a  "distributed  processing  system" 
need  to  be  described.  All  of  the  following  should  be  present  to  some 
degree  in  order  to  so  designate  a  system:  a  physical  distribution  of 
components;  multiplicity  of  components;  a  high-level  operating  system; 
system  transparency ;  autonomy;  an  effective  communications  network;  and 
a  distributed  data  base  system. 

a.  Physical  Distribution  of  Components 

The  physical  distribution  phase  of  the  components  of  a 
distributed  processing  system  refers  to  the  procedure  whereby  processors 
and  other  integral  components  of  the  system  are  physically  separated 
from  each  other.  This  separation  may  be  only  by  meters,  as  could  be 
found  in  a  manufacturing  application  located  completely  within  the 
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confines  of  one  building,  or  by  thousands  of  kilometers  as  in  the 
ARPANET  application  which  has  intercommunicating  sites  in  Hawaii,  the 
United  States  mainland,  and  in  Europe.  Descriptions  that  address 
physical  separation  of  components  as  the  only  criteria  for  a  distributed 
processing  system,  however,  are  completely  erroneous.  Although  physical 
separation  forms  a  part  of  the  definition,  a  complete  description  must 
include  the  concepts  under  which  physical  distribution  is  in  evidence, 
such  as  in  the  physical  separation  of  processing  hardware;  however,  these 
are  not  necessarily  considered  to  be  distributed  processing  systems, 
b.  Multiplicity  of  Components 

A  multiplicity  of  components  indicates  that  the  profusion  of 
general-purpose  integral  parts  of  the  system,  including  both  physical 
and  logical  resources,  must  be  present  to  form  a  dynamic  system.  It  is 
not  required  that  the  components  be  of  uniform  structure;  however,  they 
must  be  available  to  be  assigned  to  specific  tasks  on  a  rotating  basis. 
Basically,  it  is  required  that  the  system  have  the  capability  to  be 
able  to  dynamically  reconfigure  its  resources  on  a  short-term  basis  in 
order  to  provide  specific  resource  services  at  any  specified  time.  Also, 
those  elements  within  the  system  that  are  not  involved  specifically  with 
the  assignment,  cannot  have  their  normal  operations  affected  in  any  way 
by  virture  of  the  several  variations  of  interconnections  throughout  the 
system  that  may  be  permitted.  The  availability  of  these  multiple 
resources  and  the  capability  to  interconnect  and  utilize  them  effectively 
and  efficiently  are  highly  essential  prerequisites  for  the  objectives  of 
extensibility,  integrity,  performance,  and  cost  control  [7]. 
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c.  High-Level  Operating  System 

The  design  of  a  high-level  operating  system  for  the  dis¬ 
tributed  processing  system  is  crucial  since  it  must  be  concerned  with 
several  unique  characteristics  and  problems.  In  order  to  properly 
gain  access  to  the  distributed  network,  the  potential  user  not  only 
must  be  familiar  with  the  operating  system  of  the  equipment  he  is  using, 
but  the  operating  system  of  the  remote  equipment  that  is  to  be  utilized 
for  the  job  execution,  as  well  as  the  overall  system  operational  con¬ 
trols.  This  is  virtually  an  impossible  task  due  to  the  general  incom¬ 
patibility  of  operating  systems  with  each  othe".  It  is  also  a  truism 
that  information  about  the  available  resources  and  how  to  use  them  is 
difficult  to  obtain  even  for  the  individual  who  is  willing  to  learn 
the  specific  sub-systems  he  will  be  using.  Proper  design  of  the  global 
operating  system  of  the  distributed  network  will  unify  the  diverse  types 
of  local  operating  systems,  as  far  as  the  user  is  concerned,  and  present 
him  with  only  one  operating  system. 

The  development  of  a  network  operating  system  (NOS)  as  an 
integral  part  of  a  distributed  processing  system  is  thus  essential.  The 
NOS  must  be  a  collection  of  hardware  and/or  software  designed  to  enable 
the  interconnected  computer  system  to  be  employed  in  a  convenient,  reli¬ 
able,  and  cost-effective  manner.  An  effective  network  operating  system 
is  able  to  assist  users  to  exploit  the  various  resources  available  in 
the  computer  network  in  a  manner  analagous  to  the  way  in  which  a  local 
operating  system  is  able  to  provide  a  controlled  access  for  its  users  to 
its  restricted  sphere  of  control.  In  principle,  a  NOS  is  able  to  pro¬ 
vide  user  services  far  greater  in  magnitude  than  an  ordinary  operating 
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system  because  of  its  "influence  and  connections"  within  the  distri¬ 
buted  system's  multiplicity  of  resources.  There  is  a  potential  for 
system  degradation,  however,  if  the  network  operating  system  places 
too  high  of  a  reliance  on  system  components  that  are  subject  to  failure, 
without  the  employment  of  an  extensive  back-up  capability.  The  NOS 
must  therefore  be  carefully  designed  so  that  it  makes  use  of  redundant 
equipment  in  the  distributed  system  and  not  fall  into  the  trap  of 
inadvertently  reducing,  instead  of  increasing,  system  integrity.  Other, 
currently  active,  processing  nodes  within  the  system  would  then  be 
advantageously  employed  for  system  back-up  upon  notification  by  the 
network  operating  system  when  the  need  for  such  processing  transfer  is 
requi red. 

In  a  centralized,  hierarchical  processing  system,  the  opera¬ 
ting  system  is  assumed  to  have  accurate  and  up-to-date  information 
concerning  its  operational  configuration  at  any  specific  moment  in  time. 
This  may  not  necessarily  be  the  case  in  a  distributed  processing  con¬ 
figuration.  In  fact,  it  is  highly  unlikely  that  truely  complete  infor¬ 
mation  will  ever  be  available  due  to  the  inherent  time  delay  in  the 
collection  of  status  information  about  the  various  system  components.  A 
conventional  processor's  operating  system  is  able  to  request  status 
information  of  a  component  and  be  assured  of  a  reliable  answer  since 
that  single  operating  system  controls  the  activities  of  that  single 
component.  The  operating  system  is  thus  assured  that  component  status 
will  not  change  until  whatever  decisions  that  are  required  concerning 
the  interrogated  componenthave  been  made.  Due  to  the  autonomy  of  the 
distributed  system  (to  be  amplified  later),  however,  significant  time 
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lags  concerning  status  information  undoubtedly  will  develop.  Decisions 
of  the  NOS  that  concern  a  specific  device  may  thus  be  made  and  returned 
too  late  to  effectively  alter  the  operating  environment  in  the  desired 
manner.  Inaccurate  information  begets  inaccurate  decisions  which  beget 
inaccurate  actions  -  a  vicious  circle  that  has  the  potential  of  negating 
any  benefits  of  the  distributed  system. 

To  further  complicate  the  picture,  the  possibility  exists 
that  different  status  information  will  be  presented  to  the  different 
system  controlling  devices.  These  variances  may  occur  as  a  result  of 
time  delays  in  the  transmission  of  status  information,  the  intentional 
or  unintentional  shielding  of  information  from  the  various  controllers, 
or  a  hideous  combination  of  the  two.  Network  operating  systems  designers 
must  have,  therefore,  considered  the  possibilities  of  designing  the  NOS 
to  accept  and  work  with  an  error  filled,  inaccurate  system  status  infor¬ 
mation  field.  To  further  complicate  matters,  most  proposed  procedures 
for  coping  with  time  delay  induced  problems,  such  as  voting  and  software 
synchronization,  also  need  to  be  processed  by  the  system  which  results 
in  further,  possibly  catastrophic  time  delays  [8]. 
d.  System  Transparency 

System  transparency  is  that  characteristic  of  the  system 
that  provides  the  user  the  illusion  that  he  is  receiving  a  set  of 
processes  and  not  processors.  The  user  is  able  to  request  a  specific 
service  to  be  provided  and  not  be  concerned  as  to  which  specific 
serving  device  is  being  employed.  The  user  is  able  to  conmunicate  with 
the  system  in  the  development  of  routines  and  programs  as  though  he  were 
using  a  single  centralized  system.  Communication  with  the  distributed 
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system  is  normally  easier  since  the  NOS  software  is  routinely  designed 
to  interface  with  all  the  varities  of  devices,  languages,  and  data 
definitions  available  within  the  system.  Since  the  organization  of 
the  system  and  the  knowledge  of  specific  device  employment  are  usually 
kept  from  the  user,  services  are  requested  by  name  instead  of  by  device. 
The  previous  discussion  illustrates  that  a  single-processing  system 
could  provide  the  user  services  if  the  requisite  devices  were  available. 
However,  the  distributed  system  benefits  of  extensibility,  integrity, 
and  performance  probably  could  not  be  provided  under  these  conditions, 
e.  Autonomy 

Autonomy  of  the  distributed  processing  system  is  that  attri¬ 
bute  which  allows  personnel  at  the  local  operating  level  to  develop  much 
of  their  own  data  processing  procedures  without  continued  support  and 
"guidance"  from  a  central  controlling  station.  This  autonomy  is 
reflected  in  both  physical  and  logical  operations.  Physically,  message 
transmission  requires  cooperation  between  both  sender  and  receiver  so 
that  hardware  operations  can  continue  to  perform  their  assigned  trans¬ 
actions  even  though  the  centralized  controller  is  temporarily  unavail¬ 
able.  Logically,  the  same  degree  of  cooperation  between  processes  must 
exist.  Unique  or  critical  processing  can  be  handled  at  the  local  opera¬ 
ting  level  because  of  the  ease  of  local  program  development.  Operational 
activities  peculiar  to  one  operating  system  are  able  to  be  accomplished 
in  the  distributed  environment  due  to  this  cooperative  autonomy  which 
results  in  overall  systems  flexibility.  It  must  be  emphasized  that  this 
autonomous  virtue  is  not  anarchical  in  nature.  All  systems  components 
operate  under  a  controlling  set  of  procedures  which  is  reflected  in  the 
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philosophy  of  the  network  operating  system.  In  order  to  obtain  the 
system  benefits  of  extensibility,  integrity,  and  performance,  a  high 
degree  of  autonomy  is  required. 

f.  Effective  Communication  Network 

An  interprocess  communication  scheme  is  an  essential  ingre¬ 
dient  in  the  formulation  of  any  computer  network  or  uperating  system. 

A  "link"  can  probably  best  be  defined  as  a  union  of  cooperating  proces¬ 
ses.  It  is  a  general  description  of  a  logical  communications  path  in 
a  computer  interconnection  diagram.  Link  communications  provide  the 
following  advantages:  uniform  communications  are  possible  no  matter 
what  the  physical  separation  or  configuration  may  be;  all  communications 
are  message,  as  opposed  to  signal,  oriented;  the  link  can  be  structured 
so  that  processes  are  identified  by  name  or  specified  directly  accord¬ 
ing  to  functional  classi fication .  Two  basic  types  of  link  operations 
are  needed  -  one  to  put  messages  into  the  link  and  another  to  remove 
them  from  the  link.  These  two  routine  interprocess  communications  can 
be  accomplished  by  the  two  system  primitives,  SEND  and  RECEIVE 
respectively.  Their  coordinated  operation  serves  to  insure  that  exces¬ 
sive  length  messages  are  not  attempted  to  be  terminated  early,  that 
proper  receipt  occurs,  and  processes  waiting  for  the  occurrence  of  the 
event  are  properly  activated.  Two  additional  communications  primitives, 
the  SUSPEND  and  RESTART  primitives,  allow  for  the  special  case  situa¬ 
tions  of  interrupts  occurring  in  normal  operations  to  service  a  priority 
project.  These  two  primitives  will,  respectively ,  suspend  all  activities 
of  the  member  processes  of  the  interrupted  link  until  the  priority 
project  has  been  finished,  and  then  reactivate  the  regular  processing 
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at  the  point  of  suspension  [9]. 

g.  Distributed  Data  Base  Management  System 

Many  users  are  granted  access  to  vast  ranges  of  information 
through  the  employment  of  a  distributed  data  base  management  system 
which  extends  the  capacities  of  computing  systems  [10].  The  organiza¬ 
tion  of  the  data  in  the  distributed  data  base  system  is  influenced  by 
the  overall  function  of  the  system  itself,  the  geographical  distribution 
of  the  data,  and  the  designer's  philosophy.  As  such,  there  are  several 
classification  schemes  available.  Geographical  distribution  of  data 
and  directories  is  one  method.  Another  is  by  the  amound  of  redundancy 
in  which  the  data  base  is  either  partitioned  or  replicated.  Partition¬ 
ing  refers  to  the  spreading  of  the  data  base  over  several  computers, 
while  a  replicated  system  stores  some  portions  of  the  data  base  dupli¬ 
cated  at  various  storage  nodes  within  the  distributed  network. 

(1)  Redundancy,  Partitioning  usually  involves  the  division 
of  a  very  large  and  dynamic  file  among  several  back-end  processors  within 
a  distributed  system.  A  back-end  processor  is  a  computer  that  performs 
the  data  management  functions  for  one  or  more  different  computers.  Par¬ 
titioning  increases  data  accessibility,  but  usually  at  the  cost  of  more 
control  and  communications  overhead  than  is  experienced,  obviously,  with 
a  single  file  system  localized  to  a  single  computer.  Efficient  opera¬ 
tion  of  the  NOS  software  is  able  to  reduce  this  overhead,  however.  Redun¬ 
dancy  is  normally  accomplished  by  locating  specific  files  proximal  to 
the  machines  that  will  most  often  employ  them.  This  method  is  able  to 
reduce  the  amount  of  required  intermachine  connections,  often  a  limit¬ 
ing  factor  in  the  performance  of  a  distributed  data  base  system.  Another 
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benefit  of  redundancy  is  that  is  provides  for  increased  access  to  the 
multiple  copies  of  the  data,  available  back-up,  and  somewhat  decreased 
communication  time.  Redundancy  does  impose  the  tradeoffs  of  additional 
cost  due  to  increased  storage  requirements  as  well  as  the  increased  com¬ 
plexity  in  normal  file  updating. 

An  additional  problem  experienced  by  both  partitioned 
and  replicated  systems  due  to  redundancy  is  encountered  in  the  cata¬ 
loging  function  -  information  concerning  the  data  base  itself.  The 
catalogue,  often  termed  a  directory,  must  be  updated  whenever  a  file  is 
created  or  deleted,  a  major  modification  to  a  file  description  occurs, 
and  whenever  changes  to  user  access  permissions  occur.  This  redundancy 
characteristic  of  a  distributed  system  imposes  additional  cost  and  com¬ 
plexity  factors  in  updating  the  catalogue  due  to:  inherent  communica¬ 
tions  problems  of  a  geographically  distributed  data  base;  the  possibility 
of  a  broken  connection  to  the  main  network  from  a  node  when  operating  in 
local  mode  which  will  be  relected  in  out-of-date  information  for  that 
node;  and,  similar  problems  that  are  encountered  when  there  is  distri¬ 
bution  of  the  directories  in  addition  to,  or  separate  from,  the  data 
base.  A  highly  efficient  network  control  software  system  is  required 
to  correct  the  cataloging  problem.  This  software  must  be  able  to  moni¬ 
tor  each  node  to  ascertain  when  it  has  gone  into  a  local  operating  mode 
and,  upon  completion  of  the  operation,  search  it  for  transactions  that 
may  require  updating  of  the  system  catalogue.  A  catalogue  monitoring 
program  or  subroutine  also  needs  to  be  resident  so  that  each  directory 
can  be  compared  with  every  other  directory  to  make  certain  each  of  them 
contains  reliable  information  about  the  data  base.  Journalizing  of 
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catalogue  transactions  may  be  necessary  during  peak  operating  periods 
in  order  to  be  certain  that  proper  catalogue  updates  are  made. 

(2)  Data  File  Allocation.  The  allocation  scheme  for  data 
files  among  the  multiple  physical  storage  devices  available  in  the  dis¬ 
tributed  system  is  one  of  the  problems  requiring  a  solution  by  the 
database  administrator  in  order  to  optimally  employ  all  of  the  storage 
capability.  In  order  to  accomplish  this  task,  information  concerning 
real,  or  best-guess,  utilization  of  files  is  required.  It  is  very  often 
the  case  that  the  behavior  pattern  of  file  employment  is  so  dynamic  that 
the  scheme  of  file  allocation  must  be  inspected  with  a  high  frequency  to 
make  certain  of  a  continuing  optimal  allocation  scheme.  The  first  step 
is  to  allocate  files  to  the  back-end  processors,  and  then  among  the 
devices  associated  with  each  specific  back-end  processor.  Parameters 
often  associated  with  file  allocation  algorithms  for  a  distributed  data 
base  management  system  include:  the  level  of  data  sharing  which  indi¬ 
cates  a  partitioned  or  replicated  sharing  scheme  and,  if  replicated,  to 
what  extent,  the  nature  of  the  access  patterns  which  may  range  from 
query  only  to  extensive  updating  schemes;  and,  the  information  of  the 
nature  of  the  accesses  themselves  which  may  be  deterministic,  have  a 
predictable  outcome,  or  probabilistic,  with  varying  outcomes. 

Normal  file  allocation  schemes  follow  a  cost-effective¬ 
ness  analysis  procedure.  A  generalized  costing  equation  is  developed 
and  then  various  schemes  are  proposed  and  analyzed  with  the  intention 
of  minimizing  that  equation.  Total  cost  is  composed  of  the  costs  of 
updating,  inquiry,  and  storage.  Any  allocation  pattern  that  can  reduce 
one  or,  preferably,  more  of  these  components  is  desired.  Since  both 
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the  monitoring  of  file  employment  and  the  reallocation  of  files  cost 
money  in  memory  requirements  and  software  utilization,  as  well  as  occupy 
ing  linkage  paths,  an  optimal  balance  between  the  cost  of  a  suboptimal 
allocation  scheme  and  the  cost  of  reallocation  is  desired.  It  becomes 
obvious  that,  in  a  distributed  system,  the  cost  of  obtaining  files 
residing  at  other  than  local  network  nodes  is  an  important  factor  to 
consider.  The  proper  balancing  of  storage,  communication,  and  data 
base  manipulation  schemes  is  necessary  to  both  reduce  costs  and  enhance 
extensibility,  integrity,  and  performance. 

4.  Additional  Advantages  of  Distributed  Processing 

A  large  portion  of  the  appeal  of  a  distributed  processing  system 
is  due  to  the  hybrid  approach  it  offers  between  the  two  extremes  of  the 
centralized  and  decentralized  systems.  It  is  possible  for  the  distri¬ 
buted  system  to  obtain  the  best  balance  between  these  two  alternative 
types  of  basic  configurations  in  order  to  obtain  the  desired  functional 
requirement.  Additional  advantages  of  distributed  processing  systems 
can  be  summarized  as  follows:  powerful  processing  for  application  which 
require  a  large  machine,  with  full  servicing  capabilities  provided  by 
utilizing  a  central  machine  for  gross  processing  services,  with  inputs 
and  outputs  transmitted  through  the  interconnecting  communications  links 
Overall  system's  efficiency  is  increased  since,  tasks  for  which  a  large 
processor  is  not  well  suited,  such  as  on-line  editing  and  interface 
inquiry,  can  be  transferred  to  the  distributed  processors  for  action. 

Work  can  be  shifted  from  an  overloaded  processor  to  one  which 
has  a  lesser  demand  in  order  to  reduce  queue  size  during  peak  operating 
times;  the  central  technical  staff  can  support  specialists  assigned  to 
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projects  that  are  being  performed  at  local  processing  sites;  consoli¬ 
dation  of  programs  and  the  sharing  of  common  data  which  provides  for 
system  integration  of  information  processing  can  be  completed  on  the 
large  control  unit  instead  of  on  the  local  processors  when  it  is  deter¬ 
mined  to  be  more  cost-effective  to  do  so;  organizational  activities  can 
be  integrated  through  the  exchange  of  summary  data  through  the  organi¬ 
zational  hierarchy;  users  are  able  to  directly  control  and  become  more 
intimately  involved  with  organizational  activities  in  a  distributed 
system;  some  processing  nodes  can  be  dedicated  to  perform  specific 
processing  services  resulting  in  economies  of  specialization  rather 
than  attempting  to  have  each  node  capable  of  performing  all  system  ser¬ 
vices;  relatively  small  sub-systems  can  result  in  simplification  and 
additional  economy,  especially  if  a  mini  or  micro  styled  computer  is 
used  for  the  local  processing. 

Communication  cost  can  be  reduced  along  with  the  reduced  volume 
of  processing  since  much  processing  can  be  accomplished  internal  to  the 
local  processing  units  without  going  through  a  central  machine;  increased 
communications  efficiency  also  reduces  communications  costs  since  full 
messages  can  be  stored  and  then  sent  at  off-peak  periods  as  opposed  to 
sending  individual  signals  as  they  occur;  response  time  is  reduced  when 
interactive  functions  are  performed  locally;  reliability  and  security 
requirements  are  enhanced  by  local  processing;  the  prediction  and  con¬ 
trol  of  costs  of  the  central  system  can  be  more  accurately  accomplished 
through  the  use  of  dedicated  processors  for  local  functions;  distributed 
processors  are  able  to  share  common  network  software  and  data  bases; 
central  support  services  can  be  provided  on  an  on-line  real-time  basis 
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as  needed  to  the  peripheral  elements  of  the  distributed  system. 

5.  Pitfalls  to  Distributed  Processing 

Although  a  distributed  processing  system  offers  many  advantages 
which  were  summarized  above,  there  are  several  potential  pitfalls  which 
cannot  be  called  distinct  disadvantages,  but  nevertheless  pose  demon- 
stratable  hazards  to  the  full  implementation  of  a  distributed  processing 
system  [11].  There  is,  for  instance,  a  tendency  to  add  additional 
capabilities  to  the  distributed  processor  until  it  almost  becomes  a 
system  in  itself.  The  specialized  function  that  was  initially  intended 
for  the  local  processor  is  slowly  camouflaged  by  the  incremental  exten¬ 
sions  employed,  often  under  the  guise  of  scale  economy  and  low  incremen¬ 
tal  costs.  The  specialized  node  suddenly  has  evolved  into  the  miniature 
general-purpose  system  alluded  to,  without  the  accompanying  savings  of 
scale  normally  realized. 

A  distributed  data  base  management  system  often  is  faced  with 
the  major  problem  of  data  incompatibility  especially  within  systems 
composed  of  various  software  designs  incorporated  into  a  heterogeneous 
network.  Variations  in  logical  structures  become  the  problem,  and 
require  a  data  base  translation  facility.  Structural  and  query  transla¬ 
tions  are  the  two  major  components  necessary  to  be  adequately  solved  in 
order  to  homogonize  the  data  system.  One  method  of  improvement  is  to 
include  a  software  package  which  expresses  the  relationships  between 
source  and  target  bases  and  contains  a  description  of  system  data  bases 
and  a  translational  data  definition  language. 

Interesting  security  problems  are  posed  by  a  distributed  data 
base  system.  It  would  be  beneficial  to  have  the  back-end  processor 
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screen  all  requests  to  the  data  base.  However,  since  there  are  no  pro¬ 
grams  resident  within  the  back-end  processor,  it  is  impossible  to  moni¬ 
tor  data  base  activity.  A  gigantic  security  liability  is  inherent  in 
systems  which  rely  on  public  communications  facilities  to  distribute 
information,  programs,  et  cetera,  to  geographically  dispersed  locations. 
Current  technology  is  able  to  easily  monitor  transmissions  between 
these  sites.  One  recommended  solution  is  to  rely  upon  encryption  tech¬ 
niques  to  preserve  security. 

0 

Unnecessary  system  duplication  is  often  encountered  if  each 
distributed  system  project  group  is  allowed  to  proceed  independently  in 
the  development  of  its  processing  node.  Another  hazard  of  independent, 
uncontrolled  development  is  the  possibility  that  programs  and  data 
developed  under  these  conditions  may  be  incompatibly  structured  for  use 
by  the  systems.  Additional  problems  within  a  distributed  processing 
system  can  be  summarized  as  follows:  well-known  techniques  of  systems 
and  processes  design  may  be  violated  by  inept  design  practices  utilized 
by  inexperienced  personnel  that  may  be  assigned  to  a  local  processing 
unit;  development  of  a  sub-process  at  the  local  usage  level  may  induce 
degenerations  within  the  overall  system;  and,  excessive  sophistication 
may  be  attempted  unnecessarily  which  violates  the  simplicity  aspect 
desired  in  a  distributed  processing  system  and  causes  exceedingly  com¬ 
plex  technical  problems  that  may  be  difficult  to  correct. 

6.  Guidelines  For  Development  of  a  Distributed  System 

Generalization  of  the  guidelines  to  be  used  in  the  development 
and  implementation  of  a  distributed  processing  system  are  not  particu¬ 
larly  useful  since  each  system  is  normally  postulated  to  serve  some 
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particular  need  which  is  defined  by  the  specific  purpose  for  which  it 
is  to  be  designed.  Some  general  guidelines  can  be  proposed,  however, 
which  are  applicable  across  a  wide  range  of  circumstances  and  thus 
worthy  of  presentation:  the  structure  of  the  system  must  be  defined 
by  the  master  plan.  Since  independent  components  evolve  from  the  dis¬ 
tributed  system,  the  master  plan  is  an  integral  procedure  to  the 
development  in  order  for  each  subsystem  to  focus  its  attention  on 
where  it  belongs  in  the  total  scheme  of  things.  Structurally,  the 
system  can  be  dimensioned  along  many  different,  or  a  combination  of, 
dimensions  such  as  geographica’ ,  commonality  of  processing  functions, 
functional  responsibilities  and  response  time, 
a.  Simplicity 

Significant  advantages  to  a  distributed  system  occur  when  the 
components  are  maintained  as  simply  as  the  specifications  of  design  will 
allow.  System  programs  should  follow  the  rules  of  structured  design  and 
be  as  uncomplicated  as  possible  and  still  achieve  desired  results.  Data 
structures  need  to  be  designed  with  transportability  in  mind.  If  each 
distributed  component  is  limited  to  a  narrow  scope  of  functions,  simpli¬ 
city  is  enhanced.  Choosing  a  system  structure  that  allows  for  a  high 
degree  of  independence  between  the  system  components  and  the  total  sys¬ 
tem  also  results  in  an  enhancement  of  simplicity.  Increased  independence 
is  achieved  by  requiring  relatively  few  links  accessing  each  system  com¬ 
ponent,  and  limited  sharing  of  common  data  elements.  Response  time 
requirements  for  inter-component  communication  also  influence  system 
independence  in  that  the  longer  the  permitted  response  time,  the  greater 
the  resulting  independence. 
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Design  tradeoffs  occur  in  deciding  whether  to  design  for 
processing  efficiency  or  cost-effectiveness.  A  relatively  inexpensive 
system  may  not  be  optimum  from  a  processing  standpoing  and  vice-versa. 
Significant  performance  and  cost  variations  may  be  encountered  when 
balancing  these  two  important  facets  of  design  in  the  cost-benefit 
analysis  phase.  There  are  no  simple  rules-of- thumb  or  shortcut  proce¬ 
dures  available  to  the  designer.  Careful  analysis  of  each  hardware  or 
software  performance  proposal  must  be  made  against  economic  considera¬ 
tions  and  the  consequence  of  each  alternative  solution  internally  weighed 
against  all  specifications  before  the  designer  selects  a  configuration 
for  final  implementation. 

b.  Standardization 

Primary  orientation  of  a  central  coordinating  group,  who  is 
concerning  itself  with  system  design,  is  to  ensure  standardized  communi¬ 
cations  interfaces  and  adequate  means  for  allocating  and  balancing  sys¬ 
tems  resources  are  obtained.  The  following  list  of  matters  also  need  to 
be  attended  to  by  this  coordinating  group:  the  provision  of  a  central 
computing  service;  the  development  of  integrated  applications  to  be  run 
on  central  facilities;  the  development  of  administrative  functions 
orientated  toward  the  system-wide  data  base;  common  application  program 
development;  acquisition  of  technical  services  to  assist  in  the  develop¬ 
ment  of  distributed  applications;  personnel  training;  budgetary  review; 
hardware  selection  and  approval;  hardware  maintenance  requirements  and 
vendor  support;  documentation  standards;  system  security;  and,  priority 
use  standards. 
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C.  PHYSICAL  SECURITY 


Two  major  categories  of  the  physical  security  of  a  data  processing 
site  concern  protection  from  unauthorized  access  to  the  computer  instal¬ 
lation  and  necessary  precautions  to  prevent  accidental  destruction  of 
the  files  and  data  processing  equipment  [12].  Prevention  methods 
employed  to  guard  against  unauthorized  entry  during  normal  working 
hours  include:  a  receptionist  at  the  entrance  to  the  data  processing 
and  storage  area;  guard  service;  electric  locks;  a  badge  or  other 
identification  system;  restricted  entry  policy;  and,  a  pass  system  to 
authorize  the  entrance  or  exit  of  materials  from  the  site.  Protection 
methods  to  be  employed  after  normal  working  hours  include,  but  are  not 
limited  to:  guard  service  including  a  roving  patrol  feature;  door  alarms 
installed  and  periodically  tested;  and,  secure  door  locks  in  place  and 
in  use. 

Practices  to  be  taken  to  detect  and/or  minimize  destruction  of  equip¬ 
ment  and  files  from  disasters  include  protection  methods  for  fire,  water 
damage,  and  damage  from  external  events.  Fire  protection  methods  encom¬ 
pass:  charged  fire  extinguishers  throughout  the  processing  and  storage 
areas  and  their  periodic  inspection;  installation  and  testing  of  fire 
and  smoke  detection  systems;  emergency  shutoff  switches;  and,  strict 
enforcement  of  "No  Smoking"  practices.  Water  damage  may  be  caused  by 
a  leaking  roof,  broken  water  pipes  within  the  site,  and  sprinkler  system 
operation.  Protection  from  this  sort  of  damage  will  entail  installation 
of  air  conditioning,  sprinkler  system  and  building  water  shutoff  valves 
for  the  installation,  as  well  as  nonflammable  emergency  equipment  covers 
that  are  readily  available  and  easily  installed.  Protection  from  external 
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events  is  enhanced  by  the  lack  of  windows  and  other  accesses  from  the 
exterior  of  the  building.  Existing  accesses  must  be  secured  by  iron 
grillwork  and  have  secure  window  shutters  available  to  protect  the 
site  from  damage  by  hurricanes,  wind  storms,  earthquakes,  riots  and 
other  catastrophic  events. 
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II.  THE  SHIPYARD  MANAGEMENT  INFORMATION  SYSTEM 

A.  INTRODUCTION 

Information  flow  within  a  typical  naval  shipyard  has  been  placed  in 
a  critical  position  due  to  the  often  complex  nature  of  work  that  is 
accompl ished,  the  rapid  response  to  and  control  of  work  required,  as 
well  as  ever-increasing  costs.  In  order  to  effectively  manage  over¬ 
hauls  whose  total  budget  may  exceed  $150  million  annually,  shipyard 
managers  require  reliable  and  timely  information  in  order  to  enable  them 
to  make  sound  decisions  concerning  shipyard  operations  that  are  both 
mission  and  cost-effective.  The  Shipyard  Management  Information  System 
(MIS)  was  developed  for  exactly  that  purpose;  it  provides  the  shipyard 
managers  with  rapid,  accurate  information  to  assist  in  the  decision¬ 
making  process  which  in  turn  enables  the  managers  to  control  resource 
expenditure  over  the  entire  spectrum  of  shipyard  operations.  The  Ship¬ 
yard  MIS  is  able  to  provide  the  majority  of  the  operational  and  pre¬ 
dictive  information  needed  to  monitor  productivity  [13],  provided  that 
the  system  is  applied  in  the  manner  under  which  it  was  designed  to 
operate. 

B.  EVOLUTION 

The  Shipyard  Management  Information  System  obviously  did  not  suddenly 
appear  as  the  answer  to  the  shipyard  manager's  monitoring  and  control 
problems,  but  had  to  slowly  evolve  through  a  number  of  years  and  con¬ 
figurations.  The  origins  of  the  Shipyard  MIS  can  be  traced  to  the 
employment  of  electronic  accounting  machines  (EAM)  that  were  commonly 
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utilized  for  accounting  and  payroll  applications  during  and  prior  to 
World  War  II.  However,  some  shipyards  further  extended  the  EAM  capa- 
oility  to  the  processes  of  monitoring  job  order  schedules,  personnel 
skills,  and  material  inventories.  When  digital  computers  began  to 
appear  in  naval  shipyards  in  the  early  1950' s,  these  types  of  data 
were  the  ones  most  commonly  transferred  to  the  then  revol utionary 
record-keeping  system.  The  first  shipyard  computer  applications  became 
merely  high-speed  duplications  of  the  electronic  accounting  machine 
system  without  any  changes  to  the  EAM  routines. 

As  each  individual  shipyard  recognized  the  benefits  to  be  gained  from 
having  its  own  computer  in  residence,  and  the  funds  became  available, 
the  shipyard  would  obtain  a  computer  system.  Since  no  direction  or 
guidance  was  provided  by  the  Bureau  of  Ships  (BuShips),  the  forerunner 
of  the  Naval  Sea  Systems  Command,  each  shipyard  acquired  the  computer 
configuration  of  its  choice,  and  used  it  for  whatever  applications  it 
alone  preferred.  Thus,  it  was  possible  to  find  a  relatively  sophistica¬ 
ted  financial  accounting  system  at  Puget  Sound  Naval  Shipyard,  for 
example,  excellent  production  control  at  Mare  Island,  little  more  than 
payroll  applications  at  Philadelphia,  and  a  design  orientation  at  Boston. 

Prior  to  1960,  no  organized  or  standardized  approach  to  information 
processing  was  to  be  found  in  the  naval  shipyard  system.  This  situation 
could  be  partially  explained  by  the  different  ship-type  orientations  of 
the  various  shipyards.  However,  regional  differences  of  work  force  com¬ 
position  and  historical  influences  were  also  contributing  factors.  The 
reasons  for  the  differences  not  withstanding,  the  varieties  of  operations 
encountered  were  enormous.  Extreme  variations  of  nomenclature  also 
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prevailed.  A  process  known  by  one  name  in  one  shipyard  would  be  called 
something  else  in  another,  while  the  same  name  could  refer  to  widely 
differing  processes  in  others.  This  nomenclature  problem  was  further 
complicated  by  considerable  variances  in  the  planning,  processing,  and 
reporting  procedures  encountered  across  the  shipyard  complex. 

A  standardized  shipyard  data  management  system  was  initiated  by 
SECNAVINST  (Secretary  of  the  Navy  Instruction)  PI 0462 -7  of  April,  1959. 
This  instruction  undertook  to  outline  the  goals  and  objectives  for  the 
Navy-wide  use  of  automated  data  processing  (ADP)  equipment.  The  use  of 
ADP  in  the  development  of  budgets,  plans,  programs,  schedules,  and  other 
management  tools  was  directed  by  the  Instruction.  The  use  of  complimen¬ 
tary  and  standardized  automatic  data  processing  equipment,  as  well  as 
more  centrally  developed  ADP  systems  throughout  the  Navy  were  also 
called  for. 

As  a  result  of  SECNAVINST  P10462-7,  BuShips  established  a  committee 
to  investigate  the  possibilities  of  creating  a  shipyard  management  infor¬ 
mation  system-like  process  in  compliance  with  the  Instruction.  As  a 
result  of  the  efforts  of  this  group,  it  was  decided  to  develop  a 
standardized  management  information  system  for  all  naval  shipyards  in 
early  1961.  The  system  was  to  be  called  the  Bureau  of  Ships  Management 
Information  System  for  United  States  Naval  Shipyards.  This  became  the 
forerunner  of  the  current  Shipyard  Management  Information  System. 

Various  pilot  elements  of  a  standard  Shipyard  Management  Information 
System  had  been  developed  by  1962  at  the  Mare  Island  and  Philadelphia 
Naval  Shipyards.  The  first  standardized  configuration  was  designed  by 
adopting  the  best  available  system  oriented  elements  from  the  individual 
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shipyards  and  attempting  to  integrate  them  into  the  overall  system.  The 
Boston  Naval  Shipyard  assumed  the  testing  site  function  toward  the  end 
of  the  developmental  cycle.  Boston’s  goal  was  to  integrate  the  com¬ 
ponents  of  the  system  that  were  developed  by  the  other  shipyards  into  a 
cohesive  system  and  resolve  all  interface  problems  between  system  appli¬ 
cations.  At  the  completion  of  this  initial  test,  the  system  was  instal¬ 
led  in  a  total  of  six  of  ten  shipyards  who  possessed  alike  computers. 
Shipyard  managers  then  began  to  utilize  the  products  of  the  Shipyard  MIS. 

Shortly  after  the  system  was  installed,  it  became  readily  apparent 
that  should  each  individual  shipyard  be  allowed  to  generate  its  own  pro¬ 
gram  "improvements"  or  develop  its  own  unique  reports,  problems  could 
develop  with  the  required  systems  products.  Compatibility  between 
installations  would  suffer  and  gradual  disintegration  of  the  standard¬ 
ized  MIS  system  would  result.  In  July,  1965,  to  combat  this  potential 
negative  aspect,  NAVSHIPS,  as  the  8ureau  of  Ships  was  now  called,  estab¬ 
lished  the  Computer  Applications  Support  Office  (CASDO)  and  physically 
located  it  at  the  Boston  Naval  Shipyard.  CASDO  was  able  to  make  the 
necessary  changes  to  the  system  that  corrected  problems  not  previously 
revealed  by  the  Boston  test.  By  the  summer  of  1966,  the  Shipyard  MIS 
was  operational  in  seven  of  ten  shipyards.  Not  only  did  CASDO  succeed 
in  solving  the  large  number  of  the  problems  involved  in  the  initial 
design  and  provide  for  maintenance  rrocedures  of  the  large  computerized 
system,  it  also  was  able  to  provide  in-depth  documentation  of  the  system. 

By  the  late  1960's,  most  of  the  shipyards  had  obtained  standard  com¬ 
puter  configurations  thus  eliminating  the  initial  problem  of  system 
implementation.  The  unique  equipment  set-up  at  some  yards  had  led  to 
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severe  problems.  In  1973,  a  program  designed  to  revise  and  upgrade  the 
standard  system  configuration  was  started  since  must  of  the  initial 
equipment  was  becoming  badly  overloaded.  Newer  machines  offered  more 
computational  speed,  more  memory,  and  other  innovations  such  as  multi¬ 
programming,  real-time  data  storage  and  processing,  and  timesharing. 
NAVSHIP  Instruction  5260.1  of  January,  1973,  directed  the  implementation 
in  all  naval  shipyards  of  the  standard  Shipyard  Management  Information 
System  as  it  is  recognized  today. 

The  computer  configuration  that  was  chosen  for  the  new  standard 
system  was  the  Honeywell  6060  which  is  designed  primarily  for  business 
applications  in  the  COBOL  language,  but  is  able  to  support  other  problem 
types  and  languages.  This  was  considered  to  be  a  large-scale  machine 
employing  the  most  modern  technology.  The  6060  is  constructed  in  inde¬ 
pendent  module  form  which  allows  a  user  to  design  his  particular  con¬ 
figuration  to  fulfill  his  immediate  needs,  yet  allow  for  future  expansion. 
The  6060  is  able  to  support  time-sharing,  multiprogramming,  local  and 
remote  batch  processing,  and  real-time  processing  with  each  process 
having  access  to  the  same  data  base. 

C.  CONCEPTS 

The  design  of  the  Shipyard  Management  Information  System  is  based  on 
seven  underlying  assumptions  which  reflect  the  similarities  and,  to  some 
extent,  the  differences  between  shipyard  operations  and  information  sys¬ 
tem  design.  The  following  concepts  reflect  a  general  philosophy  of  man¬ 
agement  information  systems  with  a  specific  orientation  toward  shipyard 
processing  requirements:  Given  the  large  volume  of  data  flow,  an  auto¬ 
mated  system  must  be  employed  in  order  to  accomplish  the  required 
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systematic  control  and  presentation  of  shipyard  infor  ation  in  a  low- 
cost  and  timely  manner;  the  basic  automated  system  for  this  information 
should  be  standardized  in  order  to  satisfy  similar  requirements  for 
logical  solutions  to  similar  problems  throughout  the  shipyard  system 
complex. 

The  form  and  structure  of  this  standard  Shipyard  MIS  should  reflect 
the  management  philosophies  contained  in  the  controlling  Department  of 
Defense  and  Navy  policy  documents,  although  each  shipyard  would  be 
allowed  some  latitude  in  providing  for  local  requirements;  the  ultimate 
users  of  the  output  reports,  the  shipyard  managers,  should  agree  upon 
the  format  and  style  of  those  reports;  first  line  supervisors  are  to  be 
held  accountable  for  the  quality  and  timeliness  of  the  inputs  to  the 
Shipyard  MIS:  development  of  raw  data,  especially  concerning  frequency 
of  preparation,  updates,  and  refinements,  should  be  totally  under  local 
control;  and,  similar  reports  should  be  grouped  into  families  with 
major  differences  between  reports  within  a  family  being  the  manner  in 
which  the  information  is  sorted. 

D.  FORM  AND  STRUCTURE  OF  THE  SHIPYARD  MIS 

The  organization  of  the  Shipyard  Management  Information  System 
closely  follows  the  formal  departmental  organization  of  the  overall 
shipyard  itself.  Since  four  departments  are  directly  concerned  with  the 
actual  productive  work  within  a  naval  shipyard,  the  Shipyard  MIS  has  been 
designed  to  respond  to  demands  for  information  from  each  of  the  four 
departments  through  three  interrelated  functional  areas  knows  as  sub¬ 
systems.  The  Planning  and  Production  Departments  compose  the  Industrial 
Management  Subsystem,  the  Financial  Management  Subsystem  is  related  to 
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the  Comptroller  Department,  and  the  Supply  Department  in  the  concern  of 
the  Material  Management  Subsystem.  These  three  subsystems  are  further 
broken  down  to  a  total  of  eleven  functional  systems  elements  known  as 
applications.  There  are  five  additional,  relatively  independent,  appli 
cations  which  have  been  grouped  together  into  an  Administrative  Subsys¬ 
tem  because  they  support  shipyard  functions  that  are  not  primarily 
financial,  material,  nor  industrial,  but  are  necessary  for  complete 

shipyard  operations  (see  figure  4  with  a  continuation  on  figure  5)  [14] 

» 

The  subsystems  and  their  component  applications  will  be  discussed  in 
order  as  follows: 

Industrial  Management  Subsystem 

Workload  Forecasting  Application 
Production  Control  Application 
Production  Scheduling  Application 
Performance  Measurement  Application 
Design  Application 
Financial  Management  Subsystem 
Cost  Application 
Budget  Application 
Payroll  Application 

Accounts  Payable  Reconciliation  Application 
Material  Management  Subsystem 

Industrial  Material  Application 
Shop  Stores  Application 
Administrative  Subsystem 

Radiation  Exposure  Information  Application 


57 


A 


Accounts  Payable 


Accounts  Payable  Application 


Personnel  Management  Application 
Plant  Accounting  Application 
Public  Works  Application 
Depot  Maintenance  Application 

Each  application  is  designed  in  the  form  of  a  logically  independent 
module  that  is  able  to  communicate  data  to,  and  receive  data  from,  other 
modules  through  a  series  of  common  data  bases  with  each  module  capable 
of  producing  its  own  set  of  reports.  As  a  size  perspective,  the  Finan¬ 
cial  Management  Subsvstem  is  the  laraest  of  the  subsystems  since  it  is 
required  to  handle  the  majority  of  the  routine  financial  work  of  the 
shipyard.  The  Industrial  Management  Subsystem  is  intermediate  in  size, 
while  the  Material  Management  Subsystem  is  the  smallest. 

1 .  Industrial  Management  Subsystem 

The  Industrial  Management  Subsystem  of  the  Shipyard  Management 
Information  System  is  concerned  with  maintaining  uninterrupted  flow  of 
productive  work  within  the  shipyard.  In  order  to  accomplish  this,  it 
addresses  the  planning  and  scheduling  of  work,  foreceasts  of  manpower 
and  material  requirements,  identification  and  correction  of  out-of-control 
(jeopardy)  situations,  and  evaluation  of  the  results  of  the  productive 
effort.  In  order  to  provide  prospective  to  the  structure  of  this  sub¬ 
system,  and  a  general  picture  of  the  types  of  information  required  by 
shipyard  personnel  to  enable  them  to  make  wise  decisions  concerning  ship¬ 
yard  operations,  a  summary  of  the  shipyard  work  cycle  is  presented, 
a.  Industrial  Operations 

Since  the  primary  mission  of  naval  shipyards  is  to  perform 
work  in  the  conversion,  overhaul,  repair,  dry-docking,  and  to  maintain 
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a  construction  capability  for  naval  ships,  it  can  be  accurately  sur¬ 
mised  that  each  type  of  work  will  cause  some  variation  in  shipyard 
activities.  Since  an  overhaul  function  is  a  cormon  denominator  for  all 
shipyards,  that  is  the  orientation  to  be  taken  here.  However,  before 
an  overhaul  can  begin,  several  prerequisite  conditions  must  exist. 

These  are:  the  ship  must  be  totally  dedicated  to  the  uninterrupted 
accomplishment  of  the  work  (availability);  the  spectrum  of  the  work 
must  be  decided,  prioritized,  and  authorized;  sufficient  funds  must  be 
available;  and  sufficient  material  and  skilled  manpower  must  be  com¬ 
mitted  to  the  overhaul. 

Three  major  phases  of  an  overhaul  are  of  concern  to  the 
Industrial  Management  Subsystem  of  the  Shipyard  MIS:  they  are  the 
advance  planning  phase,  the  short-range  planning  phase,  and  the  actual 
overhaul  accomplishment  phase.  The  advance  planning  phase  will  vary  in 
duration  depending  upon  the  type  and  extent  of  the  overhaul  to  be  accom¬ 
plished.  Normally,  this  phase  is  a  relatively  continuous  process  extend¬ 
ing  from  two  to  eighteen  months  prior  to  the  actual  commencement  of  the 
overhaul.  As  decisions  are  made  on  repairs  and  alterations  to  be  accom¬ 
plished,  plans  will  progress  from  very  rough  and  sketchy  to  a  more 
refined  and  defined  form. 

The  short-range  planning  phase  varies  from  six  to  eight 
months  before  the  time  of  the  ship's  arrival  in  the  shipyard  until  the 
time  it  is  made  available  for  shipyard  work,  which  is  not  necessarily 
the  same  time.  During  this  phase,  preliminary  estimations  of  the  man¬ 
hours,  personnel,  materials  and  cost  of  the  repairs  and  alterations  are 
accomplished.  This  information  is  placed  on  job  orders  which  direct 


work  to  be  performed  by  component  key  operations  called  KEYOPS.  This 
phase  also  includes  an  inspection  of  the  ship  by  representati ves  of  the 
Planning  and  Production  Departments  to  determine  the  accuracy  of  initial 
estimations  and  refine  any  design  services  and  special  materials  that 
may  be  required.  An  arrival  conference  is  held  immediately  upon  the 
ship's  arrival  in  the  yard  to  review  the  scope,  priority,  and  authori¬ 
zations  of  the  job  orders  and  to  finalize  the  overhaul  plans. 

The  actual  performance  of  the  overhaul  is  the  third  phase. 

The  Production  Department  is  held  responsible  for  the  successful  comple¬ 
tion  of  the  overhaul.  A  Ship  Superintendent  is  assigned  to  each  ship  to 
serve  as  liaison  between  the  ship  and  the  yard  and  is  responsible  to  the 
Repair  Officer  for  the  coordination  and  progress. of  all  authorized  work 
that  is  summarized  by  the  individual  job  orders.  As  jobs  are  finished, 
the  Ship  Superintendent  will  witness  the  testing  of  the  completed  work 
and  obtain  certification  signatures  on  the  various  job  orders  from  the 
cognizant  shipboard  department  heads.  The  overall  effectiveness  of 
the  completed  repairs  and  alterations  will  be  demonstrated  by  the 
conduction  of  appropriate  at-sea  or  dockside  trials  prior  to  the  departure 
conference  to  certify  the  overhaul  completion  or  to  identify  any  remain¬ 
ing  items  of  work  to  be  postponed,  reassigned  to  ship's  force,  or 
el iminated. 

From  the  foregoing  summary,  it  becomes  obvious  that  an 
effective  planning  function  is  critical  to  the  smooth  operation  of  the 
overall  productive  work  cycle.  Planning  provides  the  "bench  mark"  data 
required  to  establish  control  over  the  total  overhaul.  Data  that  is  col¬ 
lected  at  the  start  of  the  cycle  includes  information  on  the  planning 
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and  scheduling  of  productive  work  primarily  as  forecasts  of  manpower 
and  material  requi rements .  Control  over  the  accomplishment  of  the 
work  results  from  detailed  comparisons  of  planned  versus  actual  expend¬ 
iture  of  time,  labor,  and  material  resources  as  well  as  an  overall 
evaluation  of  the  work  once  it  is  accomplished.  To  this  end,  the 
five  applications  of  the  Industrial  Management  Subsystem  of  the  Ship¬ 
yard  MIS  are  designed. 

b.  Workload  Forecasting  Application 

This  application  provides  three  types  of  significant  infor¬ 
mation  to  shipyard  managers:  a  forceast  of  the  overall  shipyard  work¬ 
load;  an  analysis  of  work  actually  issued  to  the  ships;  and  an  accounting 
of  man-day  expenditures  performed  against  the  issued  work.  Each  of  these 
elements  is  also  compared  against  each  other  as  well  as  to  force  avail¬ 
able  information  which  provides  a  means  of  predicting  work  force 
requirements.  A  built-in  simulation  device  allows  shipyard  managers  to 
test  the  effects  of  manipulation  of  workload  and  schedules  through  incor¬ 
poration  and  processing  of  revised  data  transaction  inputs.  These 
adjusted  and  revised  inout  factors  are  processed  through  the  MIS  as 
though  they  were  actual  data  inputs,  the  difference  being  that  the  out¬ 
put  reports  are  flagged  by  the  transaction  codes  as  potential  changes 
due  to  the  manipulative  effects  upon  manpower  and  scheduling.  These 
reports  are  available  to  a  particular  shop  or  to  the  Production  Depart¬ 
ment  on  a  request  basis. 

The  major  files  of  the  Workload  Forecasting  Application  are 
the  Force  History  File,  the  Master  Workload  Transaction  File,  and  the 
Manning  Curve  Master  File.  The  Force  History  File  stores  transactions 


63 


relating  to  manpower  availability  on  a  daily,  monthly,  and  quarterly 
basis;  both  productive  and  supportive  personnel  manpower  availability 
records  are  maintained  and  refefenced  by  ship.  The  Master  Workload 
Transaction  File  stores  all  data  on  the  forecasting  methods  employed  by 
each  shop,  work  category,  for  each  shipyard  requirement;  the  work  start 
and  work  completion  dates  as  well  as  the  number  of  man-days  in  each 
workload  estimate  are  maintained.  The  Manning  Curve  Master  Files  stores 
all  data  that  relates  to  manning  curves  employed  by  the  various  shops 
to  forecast  their  individual  workload  requirements. 

Inputs  to  the  Workload  Forecasting  Application  include  infor¬ 
mation  on  work  force  composition,  job  load  forecasting  and  material 
expenditures.  Forceast  data  are  extended  to  include  adjustments  based 
on  varying  conditions  of  performance  and  shipyard  loading  trends,  as 
well  as  actual  versus  predicted  cost.  The  forecast  is  spread  over  a 
time  domain  through  the  use  of  manning  curve  diagrams  provided  by  the 
Production  Department.  Load  data,  which  identifies  man-hours  scheduled 
and  issued  for  specific  job  orders,  is  an  additional  input  as  is  the 
actual  man-hours  expended  on  a  specific  job.  This  series  of  inputs  encom¬ 
passes  work  that  is  predicted,  issued,  and  accomplished. 

Outputs  of  the  Workload  Forecasting  Application  are  divided 
into  three  report  families:  workload  forecasting  reports,  which  inform 
shipyard  managers  of  the  anticipated  shipyard  workload  by  ship  and  shop; 
load  reports,  which  present  information  on  work  that  has  been  scheduled 
and  issued  to  the  shops;  and  force  distribution  reports  that  provide 
information  indicating  actual  man-days  expended  and  compare  current 
manning  information  for  forecast  figures  by  ship,  shop,  and  shift. 
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c.  Production  Control  Application 


The  Production  Control  Application  of  the  Shipyard  MIS  pro¬ 
vides  for  current  and  valid  information  on  the  status  of  work  within 
the  shipyard.  In  general,  this  application  enables  shipyard  managers 
to  compare  expenditures  of  manpower  and  material  to  allowances  and  to 
related  schedules.  Inputs  to  the  application  include  scheduled  shop 
manpower  loading  information,  daily  direct  labor  and  overtime  reports, 
labor  estimates,  authorized  work  listings,  scheduled  and  actual  dates 
for  all  customer  job  orders  and  associated  key  operations. 

The  major  files  of  the  Production  Control  Application  are 
the  Performance  Standards  File,  and  the  Performance  Schedule  File.  The 
Performance  Standards  File,  PROFILE,  stores  all  data  that  is  necessary 
to  compute  work  center  performance  by  type  of  measurement  standard.  The 
results  are  then  in  turn  supplied  as  inputs  to  the  predicted  end-cost 
calculation,  and  are  subsequently  transferred  to  the  Performance  Measure¬ 
ment  Application.  The  Performance  Schedule  File  stores  transactions  on 
scheduled  start  and  completion  dates  and  other  scheduling  information. 

More  than  fifteen  output  reports  grouped  into  five  report 
families  are  generated  by  the  Production  Control  Application.  On- 
request  status  reports  provide  details  on  the  status  of  all  job  orders 
by  shop  and  become  a  convenient  method  of  assessing  what  has  been  allowed 
versus  what  has  been  expended  on  each  job  in  the  shipyard.  Direct  labor 
analysis  reports  provide  managers  with  weekly  summary  information  on 
labor  expenditures  by  ship  and  serve  as  a  continually  updated  prediction 
on  the  final  anticipated  expenditures  of  direct  labor  for  each  ship  in 
overhaul.  Jeopardy  reports  identify  potential  problem  areas  in  scheduled 
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work  areas  by  indicating  which  areas  appear  to  be  endangering  proper 
job  completion,  or  are  being  overcharged.  KEYOPS  scheduled  to  start/ 
complete  reports  enable  management  to  monitor  key  operations  that  are 
scheduled  to  start  or  complete  within  a  particular  time  frame.  Pro¬ 
duction  control  reports  facilitate  the  monitoring  of  man-hours  issued 
and  man-hours  expended  versus  authorizations. 

d.  Production  Scheduling  Application 

This  application  of  the  Shipyard  Management  Information 
System  is  designed  to  assist  personnel  of  the  Planning  and  Production 
Departments  in  the  planning  and  controlling  of  shipboard  work  schedules. 
Because  of  the  normally  nonrepeti ti ve  nature  of  shipyard  work,  especially 
as  it  applies  to  a  specific  ship,  a  formal  scheduling  procedure  is 
required  which  permits  efficient  resource  utilization  and  supports  com¬ 
plete  performance  of  all  scheduled  tasks.  The  products  of  this  sched¬ 
uling  system  are  used  to  assess  changes  that  will  be  necessary  in  order 
to  meet  schedules,  and  in  determining  when  schedules  cannot  be  met.  PERT 
(Program  Evaluation  and  Review  Technique  -  used  for  managing  the  duration 
of  projects)  and  CPM  (Critical  Path  Method  -  used  to  manage  both  duration 
and  cost  of  projects)  provide  the  basic  formalized  techniques  to  be  used 
in  providing  schedules.  The  scheduling  task  is  accomplished  by  employing 
the  probabilistic  PERT  techniques  and  the  deterministic  CPM  techniques  in 
association  with  comprehensive  formulas  contained  within  the  computer 
programs. 

Inputs  to  this  application  include  descriptions  of  the  sequence 
and  extent  of  all  KEYOPS  to  be  accomplished  during  the  overhaul,  estima¬ 
ted  and  actual  start  dates,  estimated  completion  dates,  changes  to  job 
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orders,  and  event  and  activity  data.  The  Production  Scheduling  Appli¬ 
cation  is  also  able  to  accommodate  manually  developed  schedules  and 
provide  for  the  rescheduling  of  linear,  Gantt-type,  schedules  based  on 
key  events.  One  major  file  is  employed  in  the  application,  the  PERT/ 

CPM  Master  File.  This  file  stores  all  scheduled  start  and  completion 
dates  calculated  by  the  PERT/CPM  formulas,  storing  them  by  KEYOP  title 
and  key  event  number. 

More  than  forty-five  reports  are  produced  by  this  applica¬ 
tion.  They  are  broken  down  into  six  report  families  including  error 
reports,  activity  reports,  event  reports,  schedule  date  reports,  auto¬ 
matic  update  reports  and  automatic  rescheduling  reports.  Error  reports 
are  designed  to  assist  the  schedulers  in  the  correction  of  input  errors. 
Activity  reports  consist  of  differently  sequenced  listings  of  activities 
contained  within  the  total  project  network.  Event  reports  are  concerned 
with  PERT-type  event  information  relative  to  a  point  in  time.  Schedule 
date  reports  provide  shipyard  managers  with  the  latest  changes  in  project 
dates.  Automatic  update  reports  provide  automatic  measures  of  progress 
for  those  activities  in  the  overhaul  project  that  may  not  have  a  visible 
progress,  as  in  crew  training.  Automatic  rescheduling  reports  indicate 
the  results  of  automatically  rescheduling  KEYOPS. 
e.  Performance  Measurement  Application 

The  Performance  Measurement  Application  measures  the  variances 
between  planned  work  and  the  results  of  those  plans.  The  application  also 
processes  actual  scheduled  time  and  man-hour  performance  data  across  the 
shipyard  organization,  measured  against  standards  of  productive  work 
(engineering,  uniform,  estimated,  and  nonstandard)  in  areas  where  such 
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standards  may  exist.  Inputs  encompass  a  wide  variety  of  data  including 
scheduled  and  actual  shop  workload.  Design  Division  estimates,  and 
scheduled  and  actual  completion  dates  for  job  orders  and  key  operations. 
Two  files  compose  this  application:  the  Standards  Usage  File,  which 
stores  all  data  and  transactions  concerned  with  allowances  issued 
against  each  of  the  four  types  of  standards;  the  Foreman  Master  and 
Design  Data  File  which  stores  data  on  foremen  and  design  codes,  allow¬ 
ances,  expenditures  for  the  data  period,  and  design  drawing  file  numbers. 

The  four  families  of  Performance  Measurement  Application 
reports  are  schedule  performance,  allowance/expendi ture  performance, 
standards  issue,  and  standards  coverage.  Schedule  performance  reports 
provide  information  on  key  operations  completed,  jobs  ahead  and  behind 
schedule  during  the  reporting  period,  as  well  as  a  percentage  of  schedule 
adherence.  Allowance/expenditure  performance  reports  provide  further 
allowance  versus  expenditure  comparisons  clssified  into  exception,  design, 
formen,  and  standards  type  reports.  Standards  issue  reports  compare 
man-day  allowances  to  the  four  type  of  standards  and  provide  a  comparison 
of  individual  standards  allowances  with  related  total  allowances.  Stand¬ 
ards  coverage  reports  present  data  on  total  man-hour  allowances  issued 
for  each  of  the  four  standards  types, 
f.  Design  Application 

The  Design  Application  provides  shipyard  managers  with  infor¬ 
mation  which  reflects  the  status  of  the  Design' Division 's  efforts  on  Naval 
Sea  System  Command  (NAVSEA)  drawings,  $hipboard  service  alterations  (SHIP- 
ALTS),  alterations  to  ordnance  equipment  (ORDALTS),  work  items,  special 
projects,  and  test  memos  within  the  shipyard.  The  application  generates 
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current  and  historical  workload  data  as  a  basis  for  deternininq  future 
manpower  requirements,  with  related  allowances,  expenditures,  and 
schedules.  Inputs  to  the  application  include  data  on  man-hour  estimates, 
and  actual  labor  expenditures  to  locate  and/or  develop  the  required 
drawings,  test  memos,  and  special  projects. 

Three  files  are  utilized  by  this  application:  a  Master 
Description  File,  a  Historical  Data  Update  File,  and  a  Master  Schedule 
File.  The  Master  Description  File  stores  data  that  describe  all  SHIP- 
ALTS  and  work  items,  including  titles  and  numbers  of  the  documents.  The 
Master  Schedule  File  is  the  main  file  of  the  Design  Application,  it 
stores  all  data  and  transactions  concerned  with  drawing  records  including 
dates  of  issue  and  man-hours  required  to  prepare  the  drawings.  The  His¬ 
torical  Data  Update  File  stores  all  transactions  concerned  with  changes 
made  to  the  Master  Schedule  File.  The  Historical  Data  File  also  con¬ 
tains  histories  of  all  changes  to  scheduled  dates,  as  well  as  the  date 
of  actual  issue  of  each  drawing. 

Reports  generated  by  the  Design  Application  include  control 
reports,  work  package  reports,  schedule  reports,  an  evaluation  report, 
error  listings,  and  file  dump  reports.  The  principal  management  reports 
provided  by  the  application  are  the  drawing  schedules.  These  reports 
list  the  status  of  all  drawings  associated  with  each  SHIPALT  and/or  work 
item  of  a  particular  ship.  The  schedule  reports  also  provide  the  status 
of  all  drawings  required  for  any  new  construction  or  conversion  projects 
and  all  test  memos  that  may  be  associated  with  a  particular  ship. 

2.  Financial  Management  Subsystem 

The  Financial  Management  Subsystem  of  the  Shipyard  Management 
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Information  System  is  concerned  with  the  total  flow  of  industrial  money 
within  the  shipyard.  This  subsystem  provices  controls  over  basic  system 
inputs,  validates  charges  to  job  orders,  provides  for  accounting  controls 
over  productive  and  overhead  work  types,  and  generates  budgeting  data 
for  the  entire  industrial  portion  of  the  shipyard.  This  subsystem  is 
the  largest  of  all  the  subsystems  of  the  Shipyard  MIS,  providing  more 
data  and  generating  more  reports  than  any  other  subsystem.  The  four 
applications  of  the  Financial  Management  Subsystem  are  all  concerned 
with  the  Navy  Industrial  Fund. 

a.  Navy  Industrial  Fund 

The  Navy  Industrial  Fund  (NIF)  is  a  revolving  fund  established 
by  the  United  States  Congress  to  provide  naval  shipyards  with  necessary 
working  capital.  Under  provisions  of  the  NIF,  a  cash  allocation  is  made 
to  the  shipyard  at  the  time  the  fund  is  established.  The  fund  is  replen¬ 
ished  by  billing  customers  for  work  performed,  materials  supplied,  and 
is  surcharged  for  necessary  administration  and  overhead  expenses.  The 
advantage  of  an  NIF  is  that  it  provides  shipyard  managers  with  a  fiscal 
environment  which  closely  resembles  a  commercial  shipyard  activity. 
Although  a  naval  shipyard  is  designed  to  operate  on  a  break-even  basis, 
the  key  NIF  measurement  device  is  the  variations  between  predicted  and 
actual  costings  which  places  the  shipyard  managers  in  a  profit-and-loss 
situation.  Fixed  price  customer  orders  become  an  effect  of  the  NIF  on 
the  relationship  between  shipyards  and  their  customers  since  these  orders 
establish  firm  guidelines  and  incentives  for  management  to  obtain  per¬ 
formance  within  limitations  of  the  designated  fundings  which,  theoretic¬ 
ally,  encourages  efficiency  and  economy.  Accordingly,  four  application 
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areas  have  been  established  within  the  Shipyard  MIS  Financial  Management 
Subsystem:  the  Cost  Application,  the  Budget  Application,  the  Payroll 
Application,  and  the  Accounts  Payable  Reconciliation  Application, 
b.  Cost  Application 

The  Cost  Application  accomplishes  four  major  tasks  for  ship¬ 
yard  management.  First,  it  provides  the  cost  information  needed  to 
monitor  ship  availabilities;  second,  it  provides  the  expense  information 
needed  for  the  overall  financial  management  of  the  industrial  shipyard; 
third,  it  collects  the  data  required  to  generate  the  shipyard  Financial 
and  Operating  (F  &  0)  Statements;  and  fourth,  it  provides  the  means  by 
which  requests  for  additional  cost  data  from  NAVSEA  Headquarters,  other 
Navy  commands,  and  the  Department  of  Defense  can  be  answered.  The  Cost 
Application  is  the  largest  application  within  the  Shipyard  MIS  and 
processes  an  enormous  amount  of  detailed  cost  accounting  transactions 
daily,  primarily  to  shipyard  ledger  accounts. 

Along  with  accepting  transactions  utilized  within  its  own 
interest  area,  the  Cost  Application  provides  a  wide  spectrum  of  informa¬ 
tion  to  other  applications.  It  receives  raw  man-hour  expenditure  data 
and  transfers  validated  man-hour  expenditures  to  the  Production  Control 
Application's  PROFILE;  it  receives  dollar  data  on  materials  and  provides 
them  to  the  Industrial  Material  and  Shop  Store  Applications  of  the  Material 
Management  Subsystem;  and  it  receives  planned  and  work-in-progress  man¬ 
hour  data  and  provides  them  to  the  Workload  Forecasting  and  Performance 
Measurement  Applications  of  the  Industrial  Management  Subsystem. 

The  major  files  of  this  application  are  the  Cost  Master  File, 
Validation  Control  File,  and  Transaction  Master  File.  The  Cost  Master 
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File  stores  a  summary  of  all  transactions  that  are  related  to  the  cost 
of  labor  and  material  for  productive  work  in  progress  by  job  order  and 
shop,  and  includes  data  on  overhead  expenses.  The  Validation  Control 
File  contains  basic  data  on  the  Customer  Order  Acceptance  Record  (COAR) , 
plus  control  numbers  which  indicate  the  desired  level  of  validation  for 
charges,  these  control  numbers  allow  for  labor  and  material  charges  to 
be  validated  to  the  control  number,  KEYOP,  shop,  and  work  center  levels 
as  dictated  by  NAVSEA,  and  as  augmented  by  local  policy.  The  Trans¬ 
action  Master  File  stores  transactions  concerned  with  unallocated  costs, 
as  well  as  the  multitude  of  other  daily  transactions  that  are  concerned 
with  the  updating  of  shipyard  ledger  accounts;  examples  are  charges  to 
work  in  progress,  summaries  of  one-time  charges,  force  data  for  NAVSEA 
reports,  and  price  variance  data. 

The  Cost  Application  of  the  Shipyard  MIS  generates  one-hundred 
and  ten  reports  distributed  among  three  report  families.  The  families 
are:  customer  order  reports,  unallocated  cost  reports,  and  expense 
reports.  Customer  order  reports  are  the  major  funds  controlling  devices 
employed  by  the  Planning  Department.  The  status  of  dollar  expenditure 
for  each  customer  order  is  provided  and  enables  an  accurate  prediction  as 
to  the  ultimate  overhaul  labor  costs  by  ship.  This  family  also  provides 
a  report  which  can  be  used  to  detect  potential  cost  overruns  in  time  to 
permit  corrective  action.  Unallocated  cost  reports  provide  shipyard 
management  with  costing  information  that  has  not  been  specifically 
assigned  to  a  billing  account.  Expense  reports  provide  comparisons  of 
actual  charges  to  productive  and  general  expense  centers  versus  budget. 
Comparisons  are  shown  in  dollar  values  as  well  as  man-day  amounts.  This 
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family  of  reports  provides  the  information  needed  to  continuously  monitor 
expenses  and  to  detect  trends,  thereby  providing  a  tool  to  help  control 
cost  and  remain  within  budgetary  constraints. 

c.  Budget  Application 

The  Budget  Application  is  the  smallest  application  of  the 
Shipyard  MIS.  This  application  is  concerned  with:  the  generation  of 
data  to  budget  all  shipyard  work  loads  and  yard-wide  overhaul  expendi¬ 
tures;  monitoring  of  the  availability  and  adequancy  of  operating  capital; 
and  summarizing  loans  and  capital  transfers  for  the  reporting  period. 

The  Budget  Application  employs  the  budget  worksheets  as  the  primary 
input  transaction  element.  The  Budget  and  Statistics  Division  of  the 
Comptroller  Department  is  the  principle  user  of  output  information  from 
his  application.  Seven  reports  are  generated  which  summarize:  labor 
outputs  by  department;  labor  transfers  between  shops;  employee  leave; 
budget  estimates  for  overhead  by  work  centers,  departments,  and  common 
group  cost  centers;  as  well  as  providing  budget  estimates  of  total  labor 
and  materials. 

d.  Payroll  Application 

The  primary  purpose  of  the  Payroll  Application  is  to  accom¬ 
plish  timely  and  accurate  payment  of  all  naval  shipyard  employees  and  to 
generate  all  of  the  reports  required  by  shipyard  managers  to  control  and 
audit  pay  and  leave  accounts.  A  secondary  purpose  is  to  enable  compliance 
with  the  many  Department  of  Defense  and  Navy  directives  concerned  with 
naval  shipyard  payrolls.  The  application  may  also  serve  tenant  and  satel¬ 
lite  activities  in  the  management  of  employee  leave,  payroll  savings  and 
bond  programs.  In  accomplishing  these  tasks,  the  Payroll  Application 
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establishes  a  payroll  record  for  each  employee  withich  includes  per¬ 
sonnel  identification  data,  rate  of  pay,  and  payroll  deduction  data. 

A  Daily  Clock  Card  for  each  employee  is  processed  as  input,  and  records 
his  hourly  charges  or  absences.  The  data  is  converted  to  labor  and  leave 
dollars  by  the  application  which  in  turn  stores  the  information  for 
future  use  in  developing  the  payroll. 

There  are  four  files  employed  within  this  application:  the 
Pay,  Leave,  Bond,  and  Financial  Institution  Master  Files.  The  Pay  Master 
File  stores  all  historical  earnings  data  of  all  graded  and  ungraded 
employees  and  is  updated  daily  by  the  Daily  Clock  Card.  This  file  also 
contains  a  complete  pay  account  for  each  employee.  The  Leave  Master 
File  contains  the  employee  leave  accrual  and  usage  records.  The  Bond 
Master  File  stores  payroll  savings  data  and  deduction  instructions  for 
United  States  Savings  Bonds.  The  Financial  Institution  Master  File 
stores  the  addresses  of  institutions  which  employees  have  indicated  are 
to  receive  their  allotments  and/or  net  pay.  In  addition  to  the  use  of 
payroll  data  for  pay  purposes,  data  on  man-hours  and  dollars  stored  in 
the  Payroll  Master  File  are  transferred  to  the  Cost  Application  and  then 
to  the  Production  Department's  PROFILE  for  Production  Control,  Workload 
Forecast,  and  Performance  Measurement  reports. 

More  than  eighty  different  reports  are  produced  by  the  Pay¬ 
roll  Application.  Five  report  families  are  represented:  control  reports 
are  used  to  preserve  the  integrity  of  the  timekeeping  and  labor  reporting 
functions;  audit  reports  provide  the  means  to  review  and  trace  all  pay¬ 
roll  data;  payroll  savings  reports  present  data  on  the  progress  of  U.S. 
Savings  Bond  sales  and  savings  allotments  of  full-time  employees; 
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service  reports  include  the  actual  paychecks  themselves  plus  annual 
withholding  statements;  and  management  information  reports  present 
statistical  data  on  the  payroll. 

e.  Accounts  Payable  Reconcilation  Application 

Shipyard  funds  management  requires  an  entry  in  the  accounts 
payable  account  whenever  Navy  Industrial  Fund  material  is  received,  and 
an  entry  in  the  material-in-transit  account  whenever  NIF  material  is  paid 
for  prior  to  its  actual  receipt.  The  purpose  of  the  Accounts  Payable 
Reconciliation  Application  of  the  Shipyard  MIS,  is  to  provide  the 
information  needed  to  control  and  continually  reconcile  these  two  accounts. 
Ideally,  this  reconciliation  should  be  a  routine  operation,  however,  due 
to  processing  delays,  changes  in  prices,  and  partial  deliveries,  unliquid¬ 
ated  or  unreconciled  balances  have  a  tendency  to  accumulate  in  both 
accounts. 

Both  civilian  commercial  and  Navy  supply  system  transactions 
are  controlled  by  this  application  using  the  Accounts  Payable/Material- 
in-Transit  Master  File.  When  a  receipt  of  material  is  processed,  the 
transaction  will  establish  a  record  in  the  accounts  payable  fields  of  the 
file  and  blanks  in  the  material-in-transit  fields.  When  a  paid  bill 
transaction  is  received,  the  transaction  is  entered  into  the  file,  the 
two  sides  are  balanced,  and  the  record  liquidated.  The  file  also  con¬ 
tains  detailed  historical  data  on  document  numbers,  federal  stock  number 
transactions,  unit  prices,  partial  deliveries,  and  delivery  quantities. 
Fifteen  reports  are  produced  by  the  Accounts  Payable  Reconcilation 
Application,  most  of  which  are  tools  designed  to  aid  in  the  liquidation 
of  unreconciled  balances  in  the  two  accounts. 
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In  addition  to  shop  stores  and  direct  material  inventory 
information,  the  subsystem  handles  data  and  information  for  a  variety  of 
services.  Types  of  services  included  are  travel  and  transportation, 
transport  of  material,  utilities,  printing  and  reproduction,  and  other 
contractual  services.  The  commitments  for  these  services  are  treated 
like  end  use  material  and  are  identified  by  alphabetic  codes  to  desig¬ 
nate  the  particular  service  of  concern.  Shop  stores  and  direct  material 
inventory  items  may  be  obtained  by  purchase  from  local  or  national  sup¬ 
pliers,  from  main  Navy  inventories,  or  from  the  Defense  Supply  Agency  if 
the  item  requested  is  a  standard  stock  item  within  one  of  those  systems. 
All  materials  and  services  are  requisitioned  through  the  shipyard  Supply 
Department  and  entred  into  the  Shipyard  MIS  Material  Subsystem  as  material 
control  records  and  commitments  of  funds.  Two  applications  form  the 
heart  of  the  Material  Management  Subsystem:  the  Industrial  Material 
Application  and  the  Shop  Stores  Application, 
b.  Industrial  Material  Application 

This  application  of  the  Shipyard  MIS  records  and  controls  the 
procurement,  receipt,  issue,  and  where  necessary,  disposal  of  shipyard 
direct  material.  The  Industrial  Material  Application  provides  a  bridge 
of  information  between  order  recording  and  actual  material  usage  which 
spans  status  and  inventory  operations  and  leads  to  material  support  by 
job  order  and  key  operation  references.  A  major  goal  of  the  application 
is  to  provide  shipyard  managers  with  essential  information  that  is 
required  in  order  to  determine  the  quality  of  material  support  for  pro¬ 
duction.  Other  goals  include  identification  and  status  of  critical 
items,  determination  of  causes  of  excessive  direct  material  inventories, 
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determination  of  error  sources,  and  the  determination  of  the  cost  of 
residual  materials. 

The  Industrial  Management  Application  concerns  itself  with 
four  different  transaction  areas:  orders  for  goods  and  services  (commit¬ 
ments),  OMI,  financial,  and  pre-pricing  transactions.  Commitment  trans¬ 
actions  establish  new  and  liquidate  old  commitments  and  establish  the 
various  associated  delivery  dates.  DMI  transactions  add,  change,  and 
delete  Direct  Material  Inventory  data  including  orders,  requisitions, 
procurements ,  shipments,  receipts,  and  transactions  on  excess  material. 
Financial  transactions  address  old  dodlar  data  and  errors  related  to  the 
DMI  transactions.  Pre-pricing  transactions  provide  for  material  charges 
against  job  orders  before  the  material  is  received  and  the  final  price 
determined.  The  Validation  Master  File  of  the  Cost  Application  is  also 
employed  in  this  application  to  determine  whether  a  commitment  has  been 
made  to  a  valid  job  order  number. 

Inputs  to  this  application  include  commitment  data  in  the 
form  of  job  material  lists,  receipts  and  adjustment  data,  issues,  mate¬ 
rial  status,  and  file  maintenance  and  control  data.  The  application 
processes  these  inputs  and  provides  five  report  families:  exception 
reports,  status  reports,  control  reports  and  reference  reports.  Excep¬ 
tion  reports  are  used  to  report  status  data  on  all  material  classified 
locally  as  both  critical  and  in  jeopardy.  Status  reports  provide  com¬ 
prehensive  status  information  on  all  material  items  ordered,  due,  on 
hand,  and  issued.  Control  reports  provide  dollar  data  on  DMI  usage  at 
shops  and  expense  centers.  Situation  reports  include  items  for  which 
delivery  is  beyond  the  required  delivery  data.  Reference  reports 
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contain  cumulative  history  of  all  material  transactions  processed  and 
functions  as  an  aid  in  researching  material  discrepancies, 
c.  Shop  Stores  Application 

The  productive  work  of  naval  shipyards  requires  a  wide  range 
of  materials  which  must  be  defined,  ordered,  controlled,  stored,  issued, 
and  sometimes  disposed  of.  Shop  Stores  are  the  consumable  materials 
which  must  be  used  regularly  by  shipyard  shops  and  are  managed  by  the 
Shop  Stores  Application.  This  application  processes  all  inventory  trans- 
actions,  projects  material  replenishments,  prepares  various  shop  stores 
catalogues,  and  generates  a  series  of  reports  and  output  cards  that  aid 
in  controlling  stockage  levels. 

Three  files  are  maintained  by  the  Shop  Stores  Application: 
the  Stock  Item  Record  File,  the  Leger  File,  and  the  Description  File. 

The  Stock  Item  Record  File  stores  transactions  on  opening  and  closing 
balances  and  records  all  receipts,  issues,  and  expenditures  against 
each  shop  stores  item.  The  Ledger  File  maintains  opening  and  closing 
dollar  balances  for  each  shop  store,  together  with  the  accumulated 
values  of  receipts,  issues,  and  adjustments.  The  Description  File 
stores  descriptive  information  on  shop  stores  items  that  is  used  in  the 
preparation  of  replenishment  requisitions  and  material  catalogues.  In 
addition  to  maintaining  these  system  files,  the  application  automatically 
initiates  replenishment  actions  whenever  stock  balances  reach  a  pre¬ 
determined  reorder  level. 

Inputs  to  this  application  include  material  receipts  for 
shop  stores,  material  issues  for  shop  stores,  management  established 
parameters  on  the  type  and  quantity  of  output  information,  and  data  on 
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item  description  such  as  prices,  quantities  of  issue,  and  sources  of  the 
material.  Twenty  reports  are  distributed  among  the  replenishment,  stock 
status,  catalogue,  work  measurement,  and  control  report  families.  Replen¬ 
ishment  reports  project  usage  rates  into  recommended  reorder  levels  and 
dates.  Stock  status  reports  provide  total  values  of  shop  stores  includ¬ 
ing  total  value  statistics.  Catalogue  reports  assist  in  the  preparation 
of  on-hand  and  available  item  listings.  Work  measurement  reports  provide 
a  summary  of  inventories  as  well  as  statistical  measures  of  shop  stores 
activity.  Control  reports  provide  information  on  special  actions  that 
may  be  required  to  locate  stock,  correct  errors,  and  transfer  materials. 

4.  Administrative  Subsystem 

In  addition  to  the  eleven  applications  previously  discussed  within 
the  three  major  Shipyard  Management  Information  System  Subsystems,  there 
are  five  other  applications  which  serve  all  other  shipyard  functions  from 
a  common  data  base.  These  miscellaneous  applications  are  not  directly 
classifiable  into  any  specific  subsystem  since  they  are  basically  inde¬ 
pendent  functions,  but  have  been  grouped  together  into  the  Administrative 
Subsystem  for  ease  of  identification  and  reference.  They  are:  the  Radi¬ 
ation  Exposure  Information  Application,  the  Personnel  Management  Appli¬ 
cation,  the  Plant  Accounting  Application,  the  Public  Works  Application, 
and  the  Depot  Maintenance  Application. 

a.  Radiation  Exposure  Information  Application 

The  Radiation  Exposure  Information  Application  of  the  Ship¬ 
yard  Management  Information  System,  maintains  records  on  the  cumulative 
exposure  of  shipyard  personnel  to  ionizing  radiation  associated  with  naval 
nuclear  propulsion  plants  for  those  shipyards  who  maintain  a  nuclear 
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capability.  Report  families  produced  by  this  application  include  ' ndi - 
vidual  exposure  reports,  job  order  reports,  and  radiation  exposure 
reports  requi^  d  by  higher  authorities.  A  number  of  the  reports  genera¬ 
ted  by  the  application  are  required  by  the  Bureau  of  Medicine  and  Surgery, 
Energy  Research  and  Development  Agency,  and  the  Headquarters  of  the 
Naval  Sea  System  Command.  Nearly  all  of  the  remaininq  reports  are  used 
to  ensure  that  individuals  do  not  receive  more  ionizing  radiation  than 
prescribed  by  the  Bureau  of  Medicine  and  Surgery. 

The  Radiation  Exposure  Information  Application  employs  two 
files:  the  Radiation  Control  Personnel  Master  File  and  the  Job  Order 
Master  File.  The  Radiation  Control  Personnel  Master  File  contains  all 
data  transactions  needed  to  report  on  personnel  radiation  exposure, 
including  daily,  weekly,  monthly,  quarterly,  yearly,  and  life  accumula¬ 
tions  of  radiation  exposure  dosages.  Dates  are  also  maintained  in  this 
file  for  scheduling  radiation  exposure  training  and  the  periodic  medical 
examinations  required  for  continuing  qualification  of  individuals  as 
nuclear  workers.  Transactions  on  radiation  dosages  are  obtained  from 
the  Radiation  Monitor  and  the  Daily  Dosimeter  Reading  Card  which 
records  time  in  and  out  of  the  radiation  area,  job  order  number,  and 
dosimeter  reading  for  each  exposure,  including  zero  readings.  The  Job 
Order  History  Master  File  contains  job  order,  shop  number,  work  category, 
job  order  title,  and  oriqinal  and  revised  estimates  of  exposure  to  ioni¬ 
zing  radiation,  per  worker. 

b.  Personnel  Management  Application 

The  Personnel  Management  Application  of  the  Shipyard  MIS 
maintains  the  personnel  records  of  all  civilian  employees  of  the  shipyard. 
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As  part  of  this  effort,  the  application  provides  current  status  informa¬ 
tion  on  individual  employees,  maintains  files  of  pending  personnel  actions, 
and  reports  historical  and  reference  information  on  a  number  of  diverse 
classes  of  shipyard  personnel  statistics  including  turnover,  average 
grade,  position  titles,  awards,  minority  employees,  reductions  in  force, 
welder  qualifications,  marital  status  and  tenure.  In  addition,  the  appli¬ 
cation  provides  data  inputs  to  the  standardized  Navy  Automated  Civilian 
Manpower  Information  System  maintained  by  the  Office  of  Civilian  Man- 
power  Management  (OCMM);  it  serves  the  Training  Requirements  and  Infor¬ 
mation  Management  System,  also  OCMM  run;  and  it  provides  equal  opportunity 
information  and  statistical  analysis. 

All  shipyard  personnel  data  are  input  to  the  Personnel 
Management  Application  by  the  Base  Industrial  Relations  Office.  A 
matching  program  is  employed  to  edit  the  integrity  of  data  that  are 
common  to  both  the  Payroll  and  Personnel  Management  Applications.  The 
application  employs  nine  separate  files;  a  Master  Data  File  of  personnel 
statistics,  two  History  Files,  a  Position  Title  File,  a  Department  Table 
of  Organization  File,  an  Awards  File,  a  Minorities  File,  and  a  Welders 
Qualification  Master  File.  More  than  fifty  reports  are  generated  by 
this  application  to  describe  personnel  actions  and  activities.  Reports 
listings  are  available  on  demand  which  can  respond  to  almost  any  desired 
personnel  statistical  profile  by  selecting  and  listing  data  stored  in 
the  files.  Major  report  areas  are  distribution  of  civilian  personnel, 
average  grade  computations  by  department,  equal  opportunity  summaries, 
and  age  profile  reports. 


c.  Plant  Accounting  Application 

The  Plant  Accounting  Application  provides  the  controls  over 
Federal  Government  property  that  are  essential  to  comply  with  the 
statutory  requirements  of  the  Secretary  of  Defense,  and  to  fulfill  the 
objective  of  insuring  that  information  is  available  for  management  and 
technical  purposes  both  on  a  physical,  and  a  monetary,  inventory  of 
equipment  basis.  Information  concerning  Property  Class  3  (other  than 
industrial  plant  equipment)  which  includes  all  Navy-owned  property  with 
an  acquisition  cost  of  two-hundred  dollars  or  more,  and  Property  Class 
4  (industrial  plant  equipment)  with  an  acquisition  cost  of  one-thousand 
dollars  or  more,  is  required. 

Six  basic  input  functions  are  provided  to  the  Plant  Account¬ 
ing  Application.  They  are:  intial  loading  transactions  which  report 
the  acquisition  of  material;  identification  number  changes  which  update 
history  files;  changes  to  master  files;  monetary  changes  which  reflect 
depreciation  and  cost  factors;  dispositions  of  outdated  and  surveyed 
equipment;  and  transfers  of  equipment  to  the  custody  of  another  shop 
within  the  shipyard  or  to  an  external  activity.  The  Plant  Property  Clerk 
is  responsible  for  the  posting  of  the  transactions  which  reflect  the  acti¬ 
vities  concerning  plant  accounting.  Twenty  output  reports  are  divided 
into  two  report  families.  Plant  account  transactions  reports  include 
summaries  of  maintenance  activities,  a  summary  of  acquisitions,  equipment 
rejects  and  dispositions  by  class.  Plant  account  file  items  report 
equipment  items  by  nomenclature  and  Navy  identification  standard.  Quart¬ 
erly  equipment  master  lists,  plant  equipment  lists,  as  well  as  inventory 

r^v-aries  are  also  provided. 

*■ 


83 


d.  Public  Works  Application 

The  Public  Works  Application  supports  current  Public  Works 
Department  reporting  requirements.  The  objective  of  this  application 
is  to  support  facilities  requirements  in  addition  to  reporting  public 
works  performance  and  financial  accountability  in  support  of  the  ship¬ 
yard  industrial  effort.  Five  report  families  provide  information  on  the 
transportation,  controlled  maintenance,  family  housing,  maintenance  cost 
analysis  and  base  utilities  areas. 

The  transportation  report  family  provides  a  means  for 
accounting  for  transactions  processed  for  public  works  usage  including 
operation  and  maintenance  of  vehicles.  The  controlled  maintenance  family 
uses  the  Shipyard  Management  Information  System  Daily  Timecard  as  an 
input  and  produces  weekly  status  information  reflecting  progress  made 
by  individual  shops  on  Public  Works  Department  work  orders;  these  reports 
provide  for  completed  work  summaries  and  final  costings  including  man¬ 
hour  expenditures.  Maintenance  cost  analysis  reports  are  prepared  from 
data  extracted  from  the  Financial  and  Operations  File  and  reflect  fiscal 
year  cost  data  related  to  real  property  maintenance  functions. 

Family  housing  reports  provide  maintenance  status  and  occu¬ 
pancy  rate  information  on  military  family  housing  within  the  shipyard 
Public  Works  Department's  purview.  This  data  is  also  extracted  from 
the  Financial  and  Operations  File  and  is  concerned  with  categories  such 
as  flag,  officer,  and  enlisted  occupancy  statistics  as  well  as  an  over¬ 
all  cumulative  housing  report.  Utility  reports  are  prepared  on  a  monthly, 
quarterly,  and  yearly  basis  and  are  concerned  with  power  plant  operations 
for  those  shipyards  with  their  own  power  generating  facility. 
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e.  Depot  Maintenance  Application 


The  Depot  Maintenance  Application  provides  for  the  accumula¬ 
tion,  recording,  and  reporting  of  comparable  information  on  the  operations 
and  accompl ihsments  of  depot  maintenance  activities  related  to  weapons 
systems  supported  and  items  provided.  Beyond  this,  the  application 
enables  shipyard  management  to  measure  productivity,  develop  performance 
and  cost  standards,  and  determine  where  management  emphasis  should  be 
directed.  The  application  provides  the  capability  to  periodically  review 
depot  maintenance  accomplishments  in  relation  to:  planned  programs,  the 
use  of  facilities  provided  for  the  support  of  weapons  systems,  depot 
maintenance  cost  in  comparisons  with  the  alternative  of  replacement 
cost  of  a  specific  item,  and  comparative  costs  among  depot  maintenance 
activities  or  between  depot  activities  and  civilian  contract  sources  for 
the  same  type  of  work.  Also,  the  application  provides  a  catalogue  of 
maintenance  capability,  shows  where  duplication  of  industrial  capacity 
exists,  and  indicates  both  actual  and  potential  areas  for  interservice 
maintenance  support. 

Five  digit  Customer  Order  Acceptance  Record,  and  ten  digit 
job  order  numbers,  accounting  data,  availability  types  and  expenditures 
are  extracted  from  the  Cost  Master  File.  Other  required  information  is 
entered  directly  to  the  application  by  card  input.  Inputs  consist  of 
required  file  maintenance  items  provided  for  any  data  element  on  the 
Depot  Master  File  including  values  of  exchanged  material,  standardized 
inventory  processes,  and  all  codes  for  work  categories  of  all  non-shipwork 
areas. 
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The  Master  File  Extract  and  Depot  Maintenance  File  summarizes 
labor  hours,  labor  overhead  amounts,  direct  reimbursement  costs,  and 
material  totals.  It  thus  creates  an  updated  Depot  Maintenance  Master 
File  and  produces  output  card  decks  which  are  used  as  inputs  to  the 
next  activity,  and  creates  a  listing  of  all  of  the  extracted  data.  The 
Depot  Maintenance  Hold  File  creates  depot  maintenance  data  for  customer 
orders  that  have  not  yet  been  extracted  from  the  Cost  Master  File.  The 
Depot  Master  File  is  edited  quarterly  to  insure  completeness  and  validity 
of  data. 

The  Depot  Maintenance  Application  provides  ten  output  reports 
divided  into  two  output  families.  Periodicity  of  a  specific  report  may 
vary  from  monthly  to  annually  depending  on  the  requirements  of  the 
external  agency  or  shipyard  department  to  which  the  report  is  sent. 
Reports  are  produced  which  provide  for  the  functions  of  audit  control 
and  information  for  internal  management  and  higher  authority  reporting 
requirements.  These  provide  summary  information  relative  to  the  opera¬ 
tions  and  accomplishments  of  depot  maintenance  activities.  Additional 
reports  concerning  the  measurement  of  productivity,  performance  and  cost 
standards,  utilization  of  facilities,  and  depot  maintenance  costs  as 
opposed  to  potential  replacement  costs  are  also  provided.  Since  many 
shipyards  do  not  provide  weapons  maintenance  facilities,  this  applica¬ 
tion  is  not  implemented  in  all  Shipyard  Management  Information  System 
activities. 

E.  CONTROLS  OVER  THE  SHIPYARD  MIS 

The  Headquarters  of  the  Naval  Sea  System  Command  retains  the  respon¬ 
sibility  for  establishing  the  overall  policy  for  shipyard  management  and 


86 


and  the  Shipyard  Management  Information  System.  The  NAVSEA  office 
assigned  the  overall  responsibility  for  the  Shipyard  MIS  is  NAVSEA  07, 
the  Industrial  and  Facility  Management  Directorate.  Control  over  changes 
and  alterations  for  the  Shipyard  MIS  is  the  responsibility  of  the  Manage¬ 
ment  Information  System  Executive  Group  (MISEG).  This  top-level 
advisory  group  is  composed  of  three  senior  Shipyard  Commanders  who  estab¬ 
lish  policies  concerned  with  the  Shipyard  MIS  and  review  all  proposed 
system  changes. 

The  responsibility  for  the  centralized  design  and  implementation  of 
the  Shipyard  MIS  is  vested  in  the  Computer  Applications  Support  and 
Development  Office  (CASDO).  CASDO  is  an  office  of  NAVSEA  07  whose  over¬ 
all  direction  is  provided  by  the  MIS  Executive  Group,  and  is  located  in 
Boston,  Massachusetts.  CASDO  does  not  initiate  changes  but  provides 
central  guidance,  control,  and  coordination  as  it  encourages  the  users 
of  the  system  to  suggest  improvements.  CASDO  responsibilities  include: 
identification  and  definition  of  shipyard  information  and  data  systems 
requirements;  system  development;  processes  of  integration  with  other 
information  systems;  technical  direction  on  the  development  of  required 
computer  programs,  including  continuing  maintenance;  providing  assistance 
in  the  implementation  of  the  standardized  MIS  where  necessary,  including 
training  of  personnel  in  its  use;  control  of  the  standards  and  proce¬ 
dures  pertaining  to  the  design,  development,  and  implementation  of  the 
MIS,  and  any  other  shipyard  computer  based  management  system,  as  neces¬ 
sary. 

CASDO  consists  of  a  relatively  small  group  of  people  whose  backgrounds 
are  in  shipyard  operations  and  computer  systems.  CASDO  is  not  a  programming 
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office.  Should  programming  for  the  Shipyard  MIS  be  required,  CASDO 
writes  a  rigid  set  of  specifications  for  the  work  to  be  done  and  sends 
it  to  one  of  the  shipyards.  Each  shipyard  specializes  in  one  particular 
portion  of  the  MIS.  After  the  new  program  is  written,  corrected,  and 
checked  for  accuracy,  it  is  incorporated  into  the  standard  MIS  package 
and  distributed  to  all  of  the  shipyards.  Each  shipyard  originally 
employed  nine  to  twelve  progranmers  for  such  maintenance  activities. 

1 .  System  Improvements 

In  general,  the  major  thrust  toward  systems  changes  reside  with 
the  system's  users  as  encouraged  by  CASDO.  Shipyard  personnel  continu¬ 
ally  review  the  effectiveness  of  the  MIS  as  it  meets  their  needs,  identify 
problem  areas  which  reflect  trouble  or  lack  of  information  on  the  part 
of  the  user,  and,  in  turn,  report  the  problems  to  CASDO  who  reviews  and 
passes  them  on  to  MISEG  for  resolution.  MISEG  further  reviews  the  prob¬ 
lem  to  assess  its  applicability  to  all  shipyards,  to  ensure  the  proposed 
resolution  will  be  consistent  with  NAVSEA  policy,  and  to  determine  the 
technical  and  economic  feasibilities  of  a  system-wide  resolution.  CASDO 
and  shipyard  resources  are  employed  for  analysis,  programming,  and 
validation,  as  described  above,  prior  to  the  issuance  of  any  coordinated 
solution  proposed  for  inclusion  in  the  standard  computer  library  of 
operations. 

2.  Changes  to  System  Outputs 

Because  of  the  dynamic  nature  of  shipyard  management  and  infor¬ 
mation  required  for  its  support,  the  Shipyard  Management  Information 
System  design  provides  for  changes  to  the  outputs,  some  of  which  may  be 
made  almost  immediately  at  the  request  of  the  user.  Depending  on  the 
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type  of  change  requested,  a  review  for  approval  process  is  initiated  as 
outlined  below: 


Change 

Chanqer 

Accompli sted  By 

Add  new  reports;  drop 
old  reports;  correct 
reports  * 

User 

Letter  to  MISEG  indi¬ 
cating  what  changes 
are  desired  and  why 

CASDO 

Review  of  request; 
letter  to  MISEG 

Error  or  deficiency 
within  system  other 
than  with  reports 

MISEG 

Approval  to  CASDO  for 
change;  Advises  CASDO 
giving  particulars 

CASDO 

Initiates  corrective 
action 

Suggested  improvement 
(a  "good"  idea) 

User 

Proposal  letter  to 
CASDO  outlining  justi¬ 
fications  and  cost 
savings 

CASDO 

Analyze  and  forward 

MISEG 

Approval  to  CASDO  for 
change 

Change  report  parameters 

User 

Local  request  to  data 
processing  office 

Change  file  data;  correct 
errors 

User 

Local  request  to  DP 
office;  file  update 

Change  request  sequence 

User 

Local  request  to  DP 
office 

Change  report  frequency 

Computer 

Operator 

Introduces  appropriate 
transaction  code  to 
computer 

F.  FUTURE  OF  THE  SHIPYARD  MIS 

From  its  inception,  the  Shipyard  MIS  was  envisioned  to  have  three 
evolutionary  stages:  The  first  stage  allowed  individual  shipyards  a  high 
degree  of  autonomy  and  resulted  in  diverse  systems  and  equipment;  the 
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second  stage  called  for  the  evolution  of  these  systems  and  equipment 
into  an  aggregate  of  compatible,  multipurpose  subsystems,  designed  so 
that  a  high  degree  of  uniform  system  products  would  be  available  to  each 
shipyard.  This  stage  required  centrally  controlled  development  of  major 
subsystems  and  applications.  The  third  stage  is  one  of  refining  the  sub¬ 
systems,  largely  through  improvements  and  standardization  of  the  system's 
programs,  plus  an  expansion  of  system  coverage.  The  Shipyard  MIS  is 
fully  involved  in  this  stage. 

Part  of  the  plans  for  the  future  call  for  expansion  of  the  Shipyard 
MIS  through  the  design  of  new  applications  and  the  improvement  of  exist¬ 
ing  ones.  One  area  that  is  being  designed  for  addition  to  the  existing 
system  is  a  Quality  Assurance  (QA)  program.  The  QA  function  is  already 
a  large  data-handl ing  burden  for  shipyard  operating  personnel.  Another 
application  area  requiring  complete  implementation  is  tool  control.  Ship¬ 
yards  have  a  large  investment  in  hand  tools.  Since  the  full  incorporation 
of  nuclear  work  in  some  shipyards,  the  criticality  of  some  tools  has 
increased  and  it  is  now  necessary  to  provide  for  a  completely  automated 
tool  inventory  and  control  system.  An  area  of  great  importance  that 
will  improve  an  already  existing  application  by  furnishing  status  reports 
on  material  movement  within  the  shipyard  are  reports  that  will  help  to 
alleviate  a  major  shipyard  frustration:  trying  to  locate  material  known 
to  have  been  received,  but  which  is  presently  at  some  point  between  the 
receiving  dock  in  the  Supply  Department,  and  the  ship  requiring  the  mate¬ 
rial.  Development  of  a  material  progress  system  using  on-line  communi¬ 
cation  techniques  should  not  only  eliminate  this  frustration,  but  also 
save  many  productive  man-hours  needlessly  expended  in  the  search  for 
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the  material . 


As  can  be  surmised,  future  Shipyard  Management  Information  System 
objectives  will  involve  a  considerable  expansion  and  reorientation  of 
the  existing  Shipyard  MIS.  Much  of  this  expansion  will  consist  of 
adding  new  applications  to,  or  improving  on  existing  subsystems.  Because 
some  of  the  proposed  new  applications  may  not  logically  relate  to  any 
of  the  existing  subsystems,  it  may  be  necessary  to  develop  new  subsystems 
to  accommodate  them.  Careful  coordination  of  the  various  shipyard  data 
processing  centers,  CASDO,  and  the  MIS  Engineering  Group  is  required  in 
this  effort. 


III.  THE  SHIPYARD  MANAGEMENT  INFORMATION 


SYSTEM  AT  MARE  ISLAND  NAVAL  SHIPYARD 


A.  INTRODUCTION 

Mare  Island  Naval  Shipyard  is  located  in  Vallejo,  California,  at 
the  northeastern  corner  of  San  Pablo  Bay  at  the  mouth  of  the  Napa 
River.  Seaward  access  to  Mare  Island  is  obtained  through  San  Francisco 
Bay.  From  an  intial  land  purchase  by  the  Navy  of  965  acres  in  1853,  Mare 
Island  has  grown  through  land  reclamation  and  grants  to  its  present  size 
of  more  than  2,600  acres  of  hard  land  and  almost  1,900  acres  of  tide- 
lands  [15]. 

Mare  Island  Naval  Shipyard  (MINSY)  is  one  of  eight  members  of  the 
Naval  Shipyard  Complex  performing  a  wide  variety  of  functions  in  support 
of  the  United  States  Navy.  The  other  member  yards  are  located  in  Ports¬ 
mouth,  New  Hampshire;  Philadelphia,  Pennsylvania;  Norfolk,  Virginia; 
Charleston,  South  Carolina;  Long  Beach,  California;  Bremerton,  Washing¬ 
ton;  and  Pearl  Harbor,  Hawaii.  The  official  mission  of  MINSY,  and  all 
the  other  naval  shipyards  as  established  by  the  Secretary  of  the  Navy  in 
SECNAVNOTE  5450  of  21  April  1956  is; 

To  provide  logistic  support  for  assigned  ships  and  service 
craft;  to  perform  authorized  work  in  connection  with  con¬ 
struction,  conversion,  overhaul,  repair,  alteration,  dry¬ 
docking  and  outfitting  of  ships  and  craft,  as  assigned;  to 
perform  manufacturing,  research,  development,  and  test  work, 
as  assigned;  and  to  provide  services  and  material  to  ether 
activities  and  units,  as  directed  by  competent  authority. 

Although  each  naval  shipyard  is  capable  of  performing  a  variety  of 
services  in  the  accomplishment  of  this  mission,  the  Commander,  Naval  Sea 
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Systems  Command,  has  designated  special  assignments  for  each  of  the 
shipyards.  Mare  Island  Naval  Shipyard's  special  mission  involves  the 
construction,  conversion,  and  overhaul  of  all  types  of  submarines  and 
the  overhaul  of  surface  ships,  including  nuclear,  except  aircraft  car¬ 
riers  [16].  The  ship  construction  mission  has  since  been  deleted  for 
all  naval  shipyards;  however,  portions  of  this  capability  still  remain 
at  Mare  Island.  The  reactivation  of  MINSY's  submarine  construction 
capability  would  require  considerable  retooling  and  the  acquisition  and 
training  of  specialized  craftsmen  to  obtain  the  balance  of  skills  that 
are  different  from  the  present  needs  during  overhauls.  In  order  to 
adequately  reestablish  a  construction  capability  from  the  present  per¬ 
sonnel  standpoint  has  been  estimated  to  require  at  least  two  years. 

B.  ORGANIZATION 

1 •  MINSY  Overall  Organization 

Figure  6  depicts  the  organization  of  Mare  Island  Naval  Shipyard 
as  it  releates  to  the  data  processing  function,  and  shows  the  overall 
relationship  of  the  major  offices  and  departments  of  the  shipyard  to  each 
other  [17].  Primary  responsibility  for  the  operation  of  the  shipyard  is 
vested  in  the  Shipyard  Commander  (Code  100)  who  reports  directly  to 
NAVSEA  07  (Industrial  and  Facility  Management  Directorate)  on  matters 
pertaining  to  the  operation  of  Mare  Island  Naval  Shipyard.  The  nuclear 
management  structure  of  the  shipyard  is  included  for  purposes  of  contin¬ 
uity.  Within  each  organizational  block,  the  shipyard  functional  code  is 
provided  since  shipyard  offices  are  often  referred  to  by  code  instead  of 
title. 
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Figure  6  SHIPYARD  ORGANIZATION  CHART 
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NOTE  1:  Direct  Assess  to  Shipyard 
Commander  on  Nuclear  Matters 


2.  Organization  of  the  Data  Processing  Office 


I 


Figure  7  depicts  the  organization  of  the  Oata  Processing  Office 
(Code  110)  as  it  is  further  subdivided  into  an  Analysis  and  Programming 
and  an  Operations  Division.  The  Analysis  and  Programming  Division  is 
responsible  for  directing  and  coordinating  the  performance  on  non-engine¬ 
ering  automatic  data  processing  systems  design  and  analysis  studies  for 
all  organizational  components.  This  division  is  further  partitioned 
into  speciality  areas  with  specific  programmers  assigned  to  specific 
sections  of  the  Shipyard  Management  Information  System  as  their  partic¬ 
ular  area  of  expertise.  These  specialty  areas  are  concerned  with  finan¬ 
cial  and  material  applications,  and  special  projects.  Industrial  and 
advanced  programming  applications,  although  part  of  the  MINSY  data 
processing  effort,  have  a  dual  responsibil ity  to  the  Computer  Applica¬ 
tions  Support  and  Development  Office  (CASDO)  and  NAVSEA  073  (Industrial 
Activity  Management  Systems  Division)  for  maintenance  of  the  Industrial 
Subsystem  portion  of  the  Shipyard  MIS  for  the  Naval  Shipyard  Complex. 

The  Operations  Division  is  responsible  for  the  planning,  sched¬ 
uling,  and  directing  of  the  operation  of  the  data  processing  computer 
and  its  peripheral  equipment  within  the  Data  Processing  Center.  The 
division  maintains  liaison  with  all  shipyard  departments  in  order  to 
develop  a  schedule  for  the  accomplishment  of  data  processing  activities 
in  accordance  with  established  priorities.  It  also  provides  assistance 
to  the  Analysis  and  Programming  Division  in  programming  and  debugging, 
when  requested,  and  reports  difficulties  in  using  data  and  programs 
supplied  to  the  departments  and  divisions  concerned.  The  scheduling 
branch  performs  report  scheduling  and  distribution  functions.  Actual 
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equipment  operations  are  accomplished  by  the  operations  branch  on  a 
continuous  twenty- four-hours-a-day,  seven-days-a-week  shiftwork  basis. 
Keypunch  facilities  and  personnel  are  also  under  the  control  of  the 
Operations  Division.  Figure  8  provides  a  breakdown  of  personnel  man¬ 
ning  within  the  Data  Processing  Office  by  position,  paygrade  (G.  S.), 
number  of  personnel  at  that  level,  and  annual  salary  range  as  of  Octo¬ 
ber,  1979. 

C.  DATA  PROCESSING  GOALS  REALIZED 

The  primary  objective  of  Mare  Island's  data  processing  facility,  as 
summarized  by  the  head  of  the  Operations  Division  of  the  Data  Processing 
Office,  is  to:  "...  be  responsive  to  customer  requirements.  This 
facility  provides  a  service  to  the  user,  and  exists  so  that  he  has 
available  the  best  information  upon  which  to  base  his  decisions."  Thus, 
the  overall  objective  of  the  Shipyard  Management  Information  System,  as 
implemented  at  MINSY,  is  to  provide  accurate  and  timely  information  in 
an  easily  understandable  form  that  is  practical,  useful,  and  meaningful 
to  shipyard  decision-making  efforts.  Additional  goals  of  a  less  general¬ 
ized  nature  include:  cost  control,  economy,  forecasting,  planning,  flexi¬ 
bility,  and  provisions  for  expansion. 

The  MIS  aids  cost  control  by  bringing  together  in  an  integrated  data 
base  the  costs  of  labor,  material,  and  operations  which  achieve  increased 
operating  efficiency  through  better  work  scheduling  and  more  effective 
use  of  personnel,  equipment  and  inventories.  Shipyard  MIS  functions  are 
also  integrated  to  provide  economy  of  operations  in  that  similar  opera¬ 
tions  are  combined;  data  processed  in  one  functional  area  is  transmitted 
within  the  system  to  other  applications  which  require  the  same  information 
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Figure  8  DATA 

PROCESSING  OFFICE  MANNING 

POSITION 

G.S. 

NUMBER 

SALARY  RANGE 
(IN  DOLLARS) 

DIRECTOR  OF  DATA  PROCESSING 

DIRECTOR 

14 

1 

34,713 

- 

45,126 

SECRETARY 

6 

1 

12,531 

- 

16,293 

ANALYSIS  AND  PROGRAMMING  DIVISION 

HEAD  1 3 

1 

29,375 

32,110 

COMPUTER  SPECIALIST 

12 

6 

24,703 

. 

38,186 

COMPUTER  SPECIALIST 

11 

12 

20,611 

26,794 

COMPUTER  SPECIALIST 

9 

3 

17,035 

- 

22,147 

OPERATIONS  DIVISION 

HEAD 

12 

1 

24,703 

- 

38,186 

CLERK 

4 

1 

CONTROL  BRANCH 

HEAD 

10 

1 

18,760 

- 

24,385 

COMPUTER  TECHNICIAN 

9 

2 

17-035 

- 

22,147 

WAREHOUSEMAN 

6 

1 

12,531 

16,293 

COMPUTER  AID 

5 

2 

11,243 

- 

14,618 

COMPUTER  AID 

4 

1 

10,049 

- 

13,064 

LABORER 

2 

i 

8,128 

- 

10,327 

DAY  SHIFT 

SUPERVISOR 

9 

1 

17,035 

• 

22,147 

COMPUTER  OPERATOR 

7 

4 

13,925 

_ 

18,101 

KEYPUNCH  SUPERVISOR 

6 

1 

12,531 

_ 

16,293 

KEYPUNCH  LEADER 

5 

1 

11,243 

_ 

14,618 

DATA  TRANSCRIBER 

4 

9 

10,049 

13,064 

DATA  TRANSCRIBER 

3 

3 

8,592 

_ 

11,634 

COMPUTER  AID 

5 

1 

11,243 

- 

14,618 

SWING  SHIFT 

SUPERVISOR 

10 

1 

18,760 

- 

24,385 

COMPUTER  OPERATOR 

7 

4 

13,925 

— 

18,101 

KEYPUNCH  SUPERVISOR 

6 

1 

12,531 

16,293 

KEYPUNCH  LEADER 

5 

2 

11,243 

14,618 

DATA  TRANSCRIBER 

4 

10 

10,049 

13,064 

DATA  TRANSCRIBER 

3 

1 

8,592 

- 

11,634 

GRAVEYARD 

SUPERVISOR 

9 

1 

17,035 

• 

22,147 

COMPUTER  OPERATOR 

7 

3 

13,925 

18,101 

COMPUTER  OPERATOR 

5 

1 

11,243 

14,618 
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which,  in  turn,  avoids  duplication  of  effort  and  reduces  clerical  tasks. 
Formalized  Shipyard  Management  Information  Systems  methods  of  predicting 
expected  future  performance  based  on  actual  past  performance  are  avail¬ 
able  to  fulfill  the  forecasting  objective.  The  uncertainty  of  the 
future  is  minimized  using  the  planning  functions  of  the  MIS  in  that 
data  can  be  obtained,  translated,  understood  and  communicated  to  improve 
the  rationale  of  current  decisions  that  are  based  on  future  predictions. 
The  Shipyard  MIS  is  flexible  in  that  it  readily  accepts  changes  such  as 
new  data  files,  new  procedures,  and  new  output  functions.  The  modular 
design  of  the  MIS  allows  for  system  expansion  and  response  to  evolving 
managerial  requests  and  provides  for  advances  in  system  products  and 
additional  services  for  system  users. 

The  primary  functional  area  of  support  is  the  monitoring  of  the  entire 
work  process  from  planning  of  the  work  package  to  the  certification  of 
completion  by  the  cognizant  shipyard  department  head.  This  involves 
balancing  the  status  of  the  work  effort  in  relationship  to  the  predeter¬ 
mined  plans  and  schedules.  Situations  that  are  outside  the  established 
criteria  for  acceptable  performance,  based  primarily  on  time  and/or  cost 
factors,  are  then  to  be  highlighted  as  jeopardy  situations  so  that  mana¬ 
gerial  attention  may  be  applied.  Monitoring  and  control,  although  not 
generally  considered  to  be  synonomous  terms,  are  used  interchangeably 
at  Mare  Island;  they  refer  to  the  implementation  of  plans  and  the  use 
of  feedback,  as  demonstrated  by  figure  9,  so  that  shipyard  objectives 
are  optimally  attained.  The  feedback  loop  is  the  central  concept  of 
control /monitoring,  and  timely,  systematic  appraisals  of  operations  as 
provided  by  the  Shipyard  Management  Information  System  and  is  the  chief 
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means  of  providing  useful  feedback  to  enhance  shipyard  operations. 

0.  SYSTEMS  AND  APPLICATIONS  OF  MINSY's  SHIPYARD  MIS 

The  Shipyard  Management  Information  System  at  Mare  Island  Naval 
Shipyard  is  composed  of  four  subsystems  with  a  total  of  fifteen  appli¬ 
cations.  It  is  an  integrated  system  with  many  interfaces  between  appli¬ 
cations.  A  data  element  is  introduced  only  once  and  may  then  be  used  by 
many  applications.  Figure  10  illustrates  the  four  subsystems  and  how 
they  are  broken  down  into  their  component  functional  application  areas. 
Although  each  application  was  discussed  in  depth  in  Chapter  II  and  is 
completely  specified  by  reference  14,  a  brief  description  of  each  appli¬ 
cation  as  employed  at  MINSY  follows: 

The  Cost  Application  is  by  far  the  largest  single  application  of  the 
Shipyard  MIS.  It  accomplishes  four  major  tasks  for  shipyard  management. 
First,  it  provides  the  cost  information  needed  to  monitor  orders  received 
from  customers  for  work  to  be  accomplished;  second,  it  provides  the  over¬ 
head  information  needed  for  overall  financial  management  of  the  shipyard; 
third,  it  collects  the  data  required  to  generate  the  shipyard's  Financial 
and  Operating  Statements;  and  finally,  it  provides  the  means  and  resources 
to  answer  requests  for  additional  cost  data  from  the  Department  of  Defense, 
the  Naval  Sea  Systems  Command,  and  other  Navy  commands. 

The  Budget  Application  assists  in  the  development  of  the  information 
required  for  the  generation  of  the  shipyard  overhead  budget.  The  purpose 
of  the  Payroll  Application  is  to  accomplish  the  timely  and  accurate  pay¬ 
ment  of  all  shipyard  civilian  employees  and  to  generate  all  of  the  related 
reports  required  by  the  shipyard  and  various  governmental  agencies.  The 
Accounts  Payable  Reconciliation  Application  provides  the  information 
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needed  to  control  and  continually  reconcile  the  accounts  payable  account. 

The  Workload  Forecasting  Application  provides  a  forecast  of  the  over¬ 
all  shipyard  workload  for  direct  labor  personnel,  a  comparison  of  man- 
days  authorized  to  be  expended  by  scheduled  time-frame  against  available 
force,  and  an  account  of  the  expenditures  of  total  man-days  in  comparison 
to  the  authorized  and  scheduled  work.  The  Production  Scheduling  Applica¬ 
tion  supports  the  establishment  and  control  of  work  schedules.  The  Pro¬ 
duction  Control  Application  provides  information  on  the  status  of  work 
in  the  shipyard.  The  Performance  Measurement  Application  measures  vari¬ 
ances  between  planned  work  and  actual  performance.  The  Design  Applica¬ 
tion  provides  the  tools  for  managing  the  engineering  drawing  and 
specification  development  effort  of  the  shipyard. 

Shipyard  material  is  divided  into  two  types:  direct  material  and 
shop  stores.  Direct  material  is  that  material  that  is  ordered  with  a 
specific  end  use  on  customer  funded  work  identified.  Shop  stores  are 
the  consumable  and  high  usage/low  unit  value  material  items  that  are 
used  regularly  by  shipyard  shops.  The  Industrial  Material  and  Shop 
Stores  Applications  support  the  management  of  two  types  of  material. 

There  is  considerable  interface  between  the  two  applications  such  that 
the  using  shops  can  be  provided  with  a  report  identifying  the  status  of 
all  of  the  material  required  for  a  job  regardless  of  its  source. 

The  Personnel  Management  Application,  in  conjunction  with  the 
standardized  Navy  Automated  Civilian  Manpower  Information  System  (NACMIS), 
maintains  personnel  records  of  all  civilian  employees  of  the  shipyard. 

The  Radiation  Exposure  Information  Application  maintains  records  on  the 
cumulated  exposure  of  shipyard  personnel  to  ionizing  radiation  associated 
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associated  with  naval  nuclear  propulsion  plants.  The  Plant  Accounting 
Application  supports  the  inventory,  acquisition,  deletion  and  deprecia¬ 
tion  of  shipyard  property  and  equipment.  The  Public  Works  Application 
provides  information  on  operation  and  maintenance  of  transportation, 
utilities,  family  housing,  buildings,  and  other  facilities  and  equipment. 

E.  DATA  PROCESSING  INPUTS 

Input  to  the  data  processing  system  comes  from  many  sources.  Data 
may  physically  enter  the  system  on  the  standard  eighty-column  punch  card, 
the  design  of  which  is  controlled  by  various  transaction  codes  (TCs). 
Information  is  also  input  directly  into  an  application  program  by  other 
application  programs  withi\.  the  Shipyard  Management  Information  System. 
Inputs  to  the  Ship  Work  Control  System,  to  be  more  thoroughly  discussed 
later,  are  accomplished  through  terminal  processing  controlled  by  Trans¬ 
action  Processing  Applications  Programs. 

1 .  Transaction  Codes  and  Designators 

A  transaction  is  a  set  of  input  data  which  initiates  a  consistent 
operation  or  sequence  of  operations  in  a  given  computer  program.  Each 
transaction  contains  a  code  for  identification.  This  transaction  code  is 
the  means  by  which  a  program  recognizes,  classifies,  and  processes  the 
data.  The  Shipyard  MIS  uses  more  than  fifty-thousand  different  trans¬ 
action  codes  to  allow  for  effective,  economical  processing  of  the  millions 
of  elements  of  data  which  must  be  stored  in  the  Shipyard  MIS  computer 
files.  The  code  itself  is  made  up  of  three  alpha-numeric  characters  pre- 
ceeding  the  transaction  data.  The  first  character  identifies  the  appli¬ 
cation,  the  second  and  third  characters  identify  the  action  required  for 
the  computer  programs  and  prescribe  the  sequence  in  which  the  transaction 
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will  be  processed. 

Efficiency  and  economy  of  Shipyard  MIS  operations  often  neces¬ 
sitates  construction  of  a  computer  program  such  that  it  offers  various 
computational  alternatives  or  options  to  the  user,  or  allows  him  to  enter 
data  into  the  program  itself.  These  computational  alternatives  are 
obtained  by  entering  recognizable  codes  into  the  program;  these  codes 
are  termed  designators.  In  addition  to  providing  management  and  opera¬ 
ting  personnel  a  tool  to  control  the  system  options,  designators  are 
also  used  to  insert  certain  constants  that  may  be  desired  as  part  of  an 
internal  computation.  They  are  also  used  to  insert  common  elements  of 
data  that  may  be  used  by  programs  such  as  “today’s  date". 

All  inputs  are  in  a  fixed  format  as  per  input  transaction  code 
instructions  found  within  each  transaction  code  procedure.  There  have 
been  attempts  within  the  Operations  Division  of  the  Data  Processing 
Office  at  MINSY  to  invoke  free-formatting  procedures,  but  they  have  met 
with  resistance  from  local  programmers  and  the  CASDO  office  and  thus  are 
not  likely  to  be  implemented  in  the  near  future.  Since  there  are  thou¬ 
sands  of  input  transactions  within  the  family  of  structured  inputs 
intended  for  the  Shipyard  MIS  usage,  it  would  be  difficult  to  discuss 
all  of  them.  Thus,  the  thirty-two  transaction  codes  and  designators  which 
influence  the  operation  of  the  Workload  Forecasting  Application  of  the 
Industrial  Subsystem  are  summarized  in  figure  11. 

2.  Keypunch  Procedures 

Each  transaction,  if  it  is  not  presented  to  the  data  processing 
center  on  an  eighty-column  punched  card,  must  be  converted  from  the  source 
document  to  the  specific  format  required  by  the  appropriate  transaction 
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Figure  11 


INPUT  SUMMARY 


General 

Heading 

Type 

Number 

Name 

Job  Order 

TC 

566 

Establish  Job  Order 

Data 

TC 

570 

Amend  Job  Order 

TC 

^74 

KEYOP  File  Maintenance 

Time  Card 

TC 

055 

Daily  Clock  Card 

Data 

Performance 

TC 

160 

Shop  Performance  Factors 

Factors 

Forecasts 

TC 

273/4/7 

Manning  Curve 

TC 

260/1 

Ship/Project  Manning  Curve 

TC 

262/3/6 

Shi  D/Pro.iect  External  Load¬ 
ing 

TC 

264/5/7 

Ship/ Project  Fixed  Loading 

TC 

270 

PWER  Loading  by  Line  Number 

TC 

272 

PWER  Workload  Estimates 

TC 

268 

Ship/Project  Cancellations 

Estimates 

TC 

160 

Percent  of  Workload  Esti¬ 
mate  by  Shop 

Shop/Code 

TC 

271 

Shop  Roll  Adjustments 

Rol  1  s 

TC 

0003 

Availability,  Hull  Index 
Number 

TC 

269 

Absent 

Design  Card 

0002 

Branch  Code  Statistics 

Parameter 

0001/4/5 

Parameter  Months,  Time  Span 

Card 

Report  Heading 

Reporting 

Designator 

PF20259 

Work  Category  Selection 

Options 

Designator 

PF40260 

through 

40276 

Customer  Order  Selection 

Designator 

PF20254 

Report  Request 
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code  that  will  enable  the  data  to  be  inputed  to  the  Shipyard  MIS.  MINSY 

has  established  a  library  of  575  keypunch  procedures  that  assist  keypunch 

operations  in  the  conversion  of  data  from  the  source  documents  into  the 

format/layout  required  for  computer  input.  These  instructions  contain 

the  following  information: 

Document  Code 
Originator  Code 
Process  Code 

Source  Document  Indicator  with  Instruction,  if  applicable 
Field  Number  Indicator  # 

Field  Length 

Field  Descriptor 

Card  Column  Instructions: 

X/B/0:  X  =  must  be  keyed 
X/B  =  key  if  shown 
X/0  =  fill  with  zeros 
Desi gnator: 

Z/N/Z:  A  =  alphabetic  data 
N  =  numeric  data 
Z  =  right  justify  and  zero  fill 
A/N  =  alphabetic  and/or  numeric  data 
S/D  =  a  skip  or  a  duplicate  field  indicator 

Verification  requirements  are  annotated  by  the  letter  "V"  in  the  verifi¬ 
cation  field.  Each  procedure  also  contains  notes  as  to  the  disposition 
of  missing  or  incorrect  data  fields  found  as  a  result  of  verification 
procedures.  Instructions  for  the  disposition  of  source  documents  are 
also  provided. 

Source  documents  are  identified  as  to  the  proper  keypunching  proce¬ 
dure  required  by  the  shop  supervisor  prior  to  data  submission  to  the 
DP  center.  Hand-coded  entries  on  punch  cards  are  resubmitted  by  the 
keypunch  operator.  Source  documents  that  are  not  restricted  to  being 
inputed  for  processing  by  cards  are  submitted  by  batch  number  to  the 
CMC  (Computer  Machinery  Company)  key  entry  system  which  houses  the 
formatted  data  on  a  disc  until  it  is  transferred  to  the  appropriate 
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application  file  within  the  Shipyard  MIS.  Using  this  method,  a  journal 
file  of  raw  data  that  is  an  image  of  keypunch  transactions  is  kept  as 
a  backup  and  audit  trail  until  such  time  as  the  transactions  have  been 
completely  absorbed  into  the  system  (usually  one  week). 

F.  DATA  PROCESSING  PROCEDURES 

There  are  more  than  four-hundred  different  reports  that  may  be 
generated  by  the  Data  Processing  Office  at  Mare  Island  Naval  Shipyard. 
Each  of  these  reports  has  its  own  unique  processing  requi rements .  It, 
therefore,  is  difficult  to  attempt  a  description  as  to  how  each  of  these 
reports  is  generated  from  raw  data  inputs,  provide  a  listing  of  applica¬ 
tions  programs  utilized,  describe  each  file  routing  and  detail  the  sort¬ 
ing  routines  employed.  The  orientation  of  this  section,  then,  is  to 
generally  describe  data  processing  procedures  of  the  Shipyard  Management 
Information  System  at  Mare  Island  Naval  Shipyard  using  the  Daily  Force 
Distribution  Report  (PF-102A),  which  is  generated  from  the  Workload 
Forecasting  Application  of  the  Industrial  Management  Subsystem,  as  an 
example. 

1 .  Application  Programs 

Each  application  program  resident  within  the  Shipyard  MIS  is 
kept  in  its  own  binder  within  the  data  processing  center  of  MINSY.  Infor 
mation  contained  for  each  of  these  programs  include:  a  process  chart  of 
block  diagrams  illustrating  the  discs  and/or  tapes  utilized;  procedures 
for  data  extraction;  a  narrative  description  of  any  validation  require¬ 
ments,  the  read  file,  sorting  comparisons  utilized,  and  tape-write 
procedures  that  may  be  needed;  the  sort  sequence  is  given;  a  description 
of  input  descriptions  that  may  be  required  and  disposition  instructions 
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for  raw  data;  program  disposition;  periodicity  and  routing  of  output; 
description  of  constants,  variables  and  control  fields;  a  record  of 
program  changes;  halts  permitted;  interrupt  and  restart  procedures; 
associated  data  elements;  and  program  listings  as  well  as  initializing 
test  data  are  all  provided.  Two  programs  which  provide  the  majority 
of  the  processing  required  to  generate  PF-102A  are  the  Extract  and  Sort 
Program  (PF-101)  and  the  Edit  and  Update  Force  Data  Program  (PF-102). 

These  two  programs  are  further  described  below. 

a.  Program  PF-101 

The  Extract  and  Sort  Program,  PF-101,  is  a  Shipyard  MIS 
application  of  the  Honeywell  provided  Sort/Merge  Program  Family.  This 
family  of  programs  is  able  to  accept  a  wide  variety  of  data  and  task 
descriptions  and  dynamically  adjust  itself  to  the  individual  task  required 
of  it  in  order  to  provide  for  efficient  processing.  The  Sort  Function 
also  features  dynamic  adjustment  to  the  operating  environment  so  as  to 
maximize  resource  utilization  especially  during  multiprogramming  opera¬ 
tions.  Varying  input  and  output  files  are  utilized  depending  on  the 
specific  sorting  program  to  be  employed  by  the  requesting  process. 

The  Sort/Merge  Family  is  engaged  through  a  parametric  descriptor 
program  contained  via  the  General  Macro  Assembly  Program  (GMAP).  The 
parameters  for  sorting/merging  are  contained  in  macro  control  cards. 
Execution  of  the  object  program  generated  by  these  cards  calls  the  Sort/ 
Merge  (S/M)  Program  from  the  Software  System  Library  File.  The  parameters 
are  interpreted  and  the  desired  program  function  engaged  at  execution 
time.  Normal  operations  require  few  descriptive  parameters  since  stand¬ 
ardized  functions  and  file  descriptors  are  employed.  Complex  applications 
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including  merging  of  variable  with  fixed  record  lengths  or  partitioned 
records  or  any  combination  thereof,  can  be  accommodated  by  S/M.  Flexi¬ 
bility  is  gained  through  the  employment  of  optional  parameters  in  the 
required  macro  control  cards  or  by  the  inclusion  of  optional  macro  con¬ 
trol  cards. 

b.  Program  PF-102 

This  program  edits  the  Daily  Force  and  Schedule  Load  Files 
producing  an  output  runoff  (tape)  which  contains  the  two  force. reports 
in  print  format,  reports  PF-102A  and  PF-1Q2B.  These  force  distribution 
reports  pertain  mainly  to  man-hour  expenditures  on  a  day-by-day  basis. 

The  Daily  Force  (Input)  File  contains  sorted  force  records  used  to 
process  both  reports.  The  Schedule  Load  File  contains  sorted  load 
(authorized  work  force)  and  workload  forecast  records  as  inputs  to  the 
process.  The  Weekly  Summary  Input  File  contains  the  merged  overhead  force 
records  from  the  start  of  the  current  processing  week  to  the  current  data 
date,  less  one.  At  the  start  of  the  week,  a  sentinal  tape  replaces  this 
tape  since  it  has  opened  on  the  first  day  of  the  week. 

The  Print  Tape  File  contains  the  two  output  reports  as  a 
result  of  the  processing,  in  print  format.  The  Weekly  Summary  Output 
File  contains  the  merged  overhead  force  records  from  the  start  of  the 
processing  week  to  the  current  data  date.  After  completion  of  the  last 
force  run  of  the  week,  this  tpe  becomes  the  input  to  Program  PF-200, 

Force  Distribution.  Sequencing  of  records  within  the  program  is  by 
report  key  and  by  major  to  minor  sequencing  by  transaction  codes.  Man¬ 
hour  inputs  are  converted  to  man-days  and  rounded  off  to  whole  days  for 
reporting  purposes.  The  program  has  no  check  points,  and  is  scheduled 
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to  halt  only  at  the  end  of  the  job.  If  processing  should  stop  for  some 
reason,  the  program  must  be  rerun  in  its  entirety.  The  program  requires 
four  minutes  of  execution  time  and  utilizes  57,675  positions  of  core 
space. 

2.  PF-102A  Generation 

Figure  12,  with  a  continuation  to  figure  13,  is  the  block  diagram 
which  illustrates  the  generation  of  the  Daily  Force  Distribution  Summary 
Report,  PF-102A,  and  its  sister  report,  the  Daily  Force  Distribution 
Ship  by  Shop  Report,  PF-102B.  Input  is  from  three  major  areas:  expendi¬ 
tures,  load  data,  and  forecast  data.  Expenditures  information  comes  from 
time  cards  through  the  Financial  Subsystem  and  into  the  Production  Con¬ 
trol  Application  Program  PC-100  and  then  into  Program  PF-101.  Load  data 
originates  with  job  order  briefs  and  also  passes  through  the  Financial 
Subsystem  and  PROFILE  into  PF-101,  Forecast  data  originates  with  trans¬ 
action  code  input  to  Program  PF-201  from  which  the  data  are  then  trans¬ 
ferred  to  PF-101.  PF-101  extracts  and  sorts  information  in  preparation 

for  relaying  it  to  Program  PF-102  for  editing  and  force  updating  purposes 
prior  to  producing  the  reports  in  print  format. 

G.  DATA  PROCESSING  OUTPUTS 

The  primary  thrust  of  the  data  processing  facility  at  Mare  Island 
Naval  Shipyard  is  the  production  of  reports  that  are  responsive  to 
directives  from  higher  authority  as  well  as  serving  the  needs  of  the  local 
user.  There  are  more  than  four-hundred  possible  reports  available  from 
the  MINSY  Shipyard  Management  Information  System,  As  described  in  Chapter 
II  of  this  presentation,  each  functional  application  contains  one,  or 
more,  data  files  which  contributed  information  to  one,  or  more,  report 
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PF-102A  GENERATION 


Force 


families  within  that  application.  The  Workload  Forecasting  Application 
constains  three  major  files  and  three  report  families  from  which  twenty 
different  reports  are  generated.  These  reports  are  summarized  in  figure 
14,  the  Index  of  Reports.  The  purpose  of  this  section  is  to  describe  one 
of  those  reports,  the  Daily  Force  Distribution  Summary,  PF-102A. 

1.  PF-102A 

The  purpose  of  the  Daily  Force  Distribution  Summary,  PF-102A,  is 
to  assist  Production  Department  Management  in  the  monitoring  of  daily  man¬ 
hour  expenditures  of  the  various  shops  and  to  make  comparisons  with  the 
available  force.  The  report  contains  man-days  expended,  loaded,  and 
forecast  for  the  previous  day.  This  information  is  given  for  each  ship 
and  shop,  and  is  summed  for  each  availability  type  and  for  total  shipwork. 
Total  non-shipwork  (manufacturing  and  other  productive  work,  and  military 
support)  is  also  provided  for  each  shop.  Shop  rolls  with  related  absences, 
overhead,  loans,  and  borrows  are  also  presented  along  with  resulting 
available  force  figures. 

Shop  planners,  shop  heads,  and  group  heads  will  review  the  report 
to  see  if  expenditures  for  the  previous  day  were  at  levels  they  expected. 

If  expenditures  are  consistently  below  men-per-day  forecast  requirements, 
additional  manpower  assignments  may  be  in  order;  comparison  of  available 
force  to  men-per-day  forecasts  may  indicate  a  requirement  to  borrow 
additional  manpower  from  other  shops  or  shipyards,  hire  temporary  assist¬ 
ance,  or  reschedule  operations  as  necessary.  This  report  provides  a  good 
short-term  day-by-day  check  on  the  shop  manpower  situation. 

2.  Sample  PF-102A 

Figure  15  is  a  sample  PF-102A  report.  This  example  shows  items 
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Figure  14 


INDEX  OF  REPORTS 


REPORT 

NUMBER 

REPORT  TITLE 

PF-102A 

Daily  Force  Distribution  Report,  Summary 

PF-102B 

Daily  Force  Distribution  Report,  Ship  by  Shift 

PF-200A 

Overhead  Distribution  Report  by  Cost  Class-Weekly  Summary 

PF-200B 

Overhead  Distribution  Report  by  Job  Order-Weekly  Summary 

PF-209A 

Scheduled  Shop  Loading  Report,  Shop/Work  Center 

PF-212A 

Scheduled  Shop  Loading  Report,  Prod.  Dept,  by  Ship 

PF-213A 

Scheduled  Shop  Loading  Report,  Ship  by  Shop 

PF-215A 

Workload  Forcecast,  Ship  by  Shop  or  Ship  by  Code 

PF-217A 

Workload  Forecast/Schedule  Load,  Shop  or  Code 

PF-218A 

Workload  Forecast/Schedule  Load,  Production  Department 
or  Design  Division 

PF-220A 

Comments  on  Workload  Transactions 

PF-220B 

Workload  Changes  Shop  or  Code 

PF-403A 

Planned  Workload  and  Employment  Report 

PF-405A 

Design  Workload  Forecast,  1-12  Months 

PF-419A 

Workload  Forecast,  Graph,  Shop  XX 

PF-419B 

Workload  Forecast,  Graph,  Prod.  Dept. 

PF-419C 

Workload  Forecast,  Graph,  Shop  XX 

PF-4190 

Workload  Forecast,  Graph,  Prod.  Dept, 

PF-903A 

Master  Workload  Transaction  Report 

which  would  be  applicable  to  a  ship  undergoing  a  regular  overhaul  (ROH) 
availability  only.  Items  applicable  to  the  other  types  of  availabili¬ 


ties  would  be  included  under  separate  category  and  then  summarized  in 
the  TOTAL  headings.  Twenty-one  items  of  special  interest  are  highlighted 
for  their  importance  and  explained  below: 


Item  Heading 

1  SHIP/PROJECT 

2  ALL  SHOPS 

3 

4 

5  TOT 

6  LOAD 

7  WLF 

8  TOT  RO 

9  MFG  OPW 

10  MIL  SUPP 


Identification  of  Data 


The  name  of  the  ship  and  the  hull  type 
and  number.  In  the  case  of  non-shi pwork 
projects,  the  code  name  of  the  project 
is  used. 

Total  man-days  expended,  loaded,  and 
forecast  for  all  shops. 

Man-days  expended,  loaded,  and  forecast 
for  each  shop. 

Man-days  expended,  loaded  and  forecast 
for  each  ship  with  ROH  availability  type. 

Total,  Shipwork,  Man-days.  Figures  do 
not  include  manufacturing  and  other 
productive  work,  or  military  support. 

Scheduled  Load;  Average  men-per-day 
loaded  (scheduled  and  issued),  shipwork 
only,  man-days  are  in  terms  of  will  cost. 

Forecast,  Men-per-Day;  Average  men-per- 
day  for  shipwork  only. 

Total  Regular  Overhaul;  Total  number  of 
man-days  expended  (regular  time),  loaded, 
and  forecast,  plus  that  expended  for 
overtime  (OT )  for  ships  within  the  avail¬ 
ability  type. 

Manufactured  and  Other  Productive  Work; 
Repoted  in  man-days  for  work  expended, 
TOT,  loaded,  LOAD,  and  forecast,  WLF. 

Military  Support  in  man-days  for  work 
expended,  TOT,  loaded,  LOAD,  and 
forecast,  WLF. 
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11 


12 


13 

14 


15 

16 


17 

18 

19 


20 

21 


NON-MATCHED 

TOT  PROD 

SHOP  ROLLS 

ABSENT 

TOT  MAI  NT 

TOT  OPER 

LOANS  (SHYPD) 
LOANS  (EXT) 
BORROWS  (SHYPO) 

BORROWS  (EXT) 

AVAIL  FORCE 
(PROD) 


Charges  which  do  not  meet  assigned  level 
of  validation  criteria  and  unreported 
straight  time  under  eight  hours. 

Total  Production  Work;  Including  ship- 
work,  manufacturing,  and  other  pro¬ 
ductive  work  military  support,  overtime 
and  non-matched. 

Total  number  of  workers  assigned  to  all 
shops,  and  to  each  shop. 

Employees  on  shop  rolls  who  are  not 
available  for  performance  of  productive 
work. 

Total  Maintenance;  the  sum  of  work 
expended  for  maintenance  categories. 

Operating  Total;  sum  of  the  projections/ 
expenditures  incurred  for  operating 
costs . 

Loans,  Internal;  the  number  of  employees 
loaned  to  other  shops  within  the  shipyard. 

Loans,  External;  the  number  of  employees 
loaned  to  other  shipyards,  by  shop. 

Borrows,  Internal;  the  number  of  employ¬ 
ees  borrowed  from  another  shop  within 
the  shipyard. 

Borrows,  External;  the  number  of  employ¬ 
ees  borrowed  from  other  shipyards. 

Available  Force;  the  number  of  employ¬ 
ees  within  a  shop  that  are  available 
for  assignment  to  productive  work. 


H.  HONEYWELL  6060  SYSTEM 

In  1973,  as  part  of  the  Shipyard  Management  Information  System  improve¬ 
ment  program  designed  to  upgrade  data  processing  throughout  the  Naval 
Shipyard  Complex,  Mare  Island  acquired  a  multidimensional  Honeywell  6060 
Information  System.  The  6060  was  especially  designed  for  large-scale 
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data  handling  based  on  the  C080L  language.  It  relies  on  an  index-sequen¬ 
tial  method  of  file  processing  and  incorporates  a  powerful  database 
management  system.  Multiprogramming  is  supported  in  that  up  to  sixty- 
three  programs  may  be  in  concurrent  execution.  The  versatility  of  the 
6060  operating  system  allows  the  following  features:  integration  of 
local  batch  processing,  remote  batch,  remote  access,  transaction  proces¬ 
sing,  interactive  remote  job  entry,  on-line  document  handling  and  time¬ 
sharing  for  maximum  system  utilization.  Memory  is  organized  into  1,924 
record  blocks,  each  memory  module  contains  256  blocks  (262,144  words) 
allowing  for  over  1.5  million  words  of  main  memory.  One  central  processor 
is  in  residence  with  384,000  words  of  memory  [18].  Other  system  components 
and  characteristics  include: 

Basic  Cycle  Time  =  500  nano-seconds 

Effective  Cycle  Rate  =  16  nano-seconds  per  byte 

Six  On-Line  Model  181  Disc  Units,  one  additional  back-up  unit  avail¬ 
able 

Positioning  Time  =  10  milli-second  minimum 
34  milli-second  average 
60  milli-second  maximum 
Transfer  Rate  *  416,000  characters  per  second 
Total  Removeable  Characters  =  27.6  Million  per  disc 
One  Character  =  6  bits 
384  Characters  per  sector 
18  Sectors  per  Track 
6,912  Characters  per  Track 
20  Tracks  per  Cylinder 

Eight  None-Track  1,600  bpi  Tape  Units,  one  additional  back-up  unit 
available 

Rewind  Speed  =  500  ips 

Transfer  Rate  =  42,000  bps 

Inter-Record  Gap  =  1,200  bits  (3/4  inch) 

Tape  Length  =  2,400  feet 

Reader  Speed  =  1,050  cards  per  minute 

Printer  Speed  =  1,200  lines  per  minute 

1 .  6060  Operating  System 


Functions  of  the  General  Comprehensive  Operating  System  (GCOS)  of 
the  Honeywell  6060  Information  System  provide  for  logical  programmer  and 
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operator  interfaces  with  the  software  system,  provide  for  a  common  file 
protection  and  access  control  that  is  accessible  from  all  processing 
modes,  and  maximize  system  availability  through  a  comprehensive  total 
on-line  testing  system.  To  perform  these  functions  with  the  efficiency 
required  for  the  MINSY  mul ti-dimensional  operations,  GCOS  serves  as  the 
overall  manager  for  the  operation  of  the  integrated  hardware/software 
system.  As  system  manager,  it  is  able  to  achieve  maximum  utilization 
of  the  total  hardware  system  and  supervise  the  multiprocessor/multipro- 
arammina  environment  -  MINSY  *  s  normal  operatinq  mode.  Significant  GCOS 
features  that  are  required  to  perform  these  functions  are  implemented 
as  modules,  programs,  and  subroutines, 
a.  Functional  Components 

Major  functional  components  of  the  6060  operating  system 
include,  with  a  brief  description  of  each:  a  startup  program  package 
which  provides  a  variety  of  system  startup  operations  including  the 
loading,  initialization,  and  utility  functions  required  for  system  startup, 
or  restart  following  a  system  fault;  system  input  modules  allow  for  multi  - 
input  streams  by  accepting  input  from  all  system  input  devices  into  core 
only  when  needed;  the  system  scheduler  uses  the  job  priorities  and  classes 
processed  in  the  system  input  program  to  establish  a  dispensing  queue  to 
fit  the  requirements  of  the  user's  operation;  the  dispatcher  keeps  as 
many  system  components  as  possible  in  simultaneous  use  by  selecting  the 
highest  priority  program  that  can  make  immediate  use  of  a  processor  and/or 
a  peripheral  subsystem;  the  peripheral  allocator  module  schedules  and 
allocates  all  peripheral  devices  used  by  the  system;  the  memory  alloca¬ 
tion  function  performed  by  the  core  allocator  allocates  memory  space  to 
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jobs  entered  into  the  system  for  processing.  Operator-system  interface 
messages  are  also  available  for  exchange  between  system  orograms  and  the 
system  console  and  are  controlled  by  a  GCOS  module. 

b.  Fault  Processing 

The  method  by  which  faults  are  processed  depends  on  whether 
the  fault  occurred  within  the  system  or  within  a  slave  program.  If  a 
system  fault  occurred,  an  error  message  is  sent  to  the  system  console, 
and  the  content  of  the  registers  at  the  time  of  the  fault  are  dumped.  If 
a  noncontrol  processor  found  the  fault,  it  requests  an  interrupt  from  the 
control  processor.  The  control  processor  puts  the  noncontrol  processor 
in  a  DIS  (Display  until  Interrupt  Signal)  state  and  takes  the  dump.  If 
the  control  processor  detects  the  fault,  it  puts  the  noncontrol  processors 
in  a  DIS  state  and  takes  the  dump.  If  a  program  fault  is  encountered  when 
operating  in  the  slave  mode,  the  fault  causes  interrogation  of  the  user 
fault  vectors.  If  the  user  specifies  a  fault  processing  subroutine,  con¬ 
trol  is  transferred  via  this  vector  back  to  the  slave  activity.  If  no 
fault  processing  routine  is  specified  in  the  user  fault  vector,  an  abort 
is  set  into  the  user  program  and  control  is  transferred  to  the  GCOS,  for 
fault  correction  if  possible.  Faults  that  can  be  user  processed  are  memory, 
divide-check,  ovdrflow,  command,  illegal  procedure,  fault  tag,  and  derail. 
Normally  a  second  attempt  to  process  a  fault  of  the  last  four  types  will 
cause  the  program  to  fully  abort.  Those  faults  that  cannot  be  processed 
by  the  user  are  lockup,  parity,  operation-not-complete,  startup,  timer 
runout,  and  shutdown. 

c.  Input-Output  Supervisor 

The  Input-Output  Supervisor  (IOS)  performs  the  acceptance. 
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initiation,  and  termination  of  all  input/outDut  (I/O)  reauests.  I/O 
operations  on  the  system  are  accomplished  by  using  a  memory  I/O  opera¬ 
tion  instruction  which,  when  followed  by  pertinent  I/O  parameters,  give 
control  to  IOS  to  initiate  activity  on  the  peripheral  subsystems  or 
to  the  routine  handler  to  perform  the  I/O.  Capabilities  of  IOS  include 
symbol ic-to-physical  unit  translations  which  cause  symbolic  file  desig¬ 
nators  employed  by  programmers  to  be  converted  to  absolute  physical 
assignments  at  execution  time.  Simulated  tape  processing  on  disc  simu¬ 
lates  the  serial  mode  of  data  processing  normally  associated  with  magnetic 
tape  to  be  performed  on  disc  which  provides  a  degree  of  divide  indepen¬ 
dence  to  the  svstem  and  allows  reduction  in  Drogram  setup  time  bv  eli¬ 
minating  maanetic  tape  use  for  some  files.  IOS  responds  to  all  interrupts 
and  takes  appropriate  action  thus  allowina  the  programmer  to  be  relatively 
free  of  concern  for  the  interrupt  svstem  of  the  computer.  IOS  maintains 
aueues  of  I/O  commands  but  will  not  necessarily  select  gueued  commands 
for  execution  in  the  order  in  which  chey  were  submitted  unless  they  are 
presented  by  a  linked  file.  IOS  maintains  awareness  of  the  status  of 


each  individual  peripheral  device  in  standby  and  ready  modes.  IOS 
verifies  that  the  user  has  been  granted  permission  for  the  permanent 
file  access;  IOS  will  also  keep  a  record  of  the  time  spent  by  the  proces¬ 
sor  and  each  peripheral  device  for  every  program  executed.  These  statis¬ 
tics  are  later  recorded  on  the  accounting  file  and  printed  on  the 
execution  report  for  later  use  in  billing  and  system  operation  analysis. 

2.  Data  Base  Manager 

Oata  base  manager  functions  are  provided  by  the  File  Management 
Supervisor  (FMS)  routines  which  provide  for  cataloging,  control  of  storage 


space,  prevention  of  unauthorized  access,  protection  against  device 
failure,  partial  protection  against  incomplete  or  incorrect  update,  and 
protection  against  concurrent  usage, 
a.  Cataloging 

Cataloging  is  the  method  by  which  information  concerning  the 
file  is  kept  and  thus  is  the  basis  for  all  other  services.  Cataloging 
services  allow  files  to  be  created  and  deleted  and  their  descriptions  to 
be  grouped  and  modified.  The  FMS  administers  a  structure  of  mass  storage 
records  to  keep  track  of  information  about  files  and  authorized  users.  A 
separate  substructure  is  created  for  each  user  to  record  information  about 
files  and  authorized  users.  A  separate  substructure  is  created  for  each 
user  to  record  information  about  files  catalogued  under  that  user  name. 

A  System  Master  Catalogue  (SMC)  is  employed  as  an  index  to  these  sub¬ 
structures.  The  SMC  has  an  entry  for  each  user  authorized  to  reference 
catalogued  files,  to  use  the  Time-Sharing  System,  or  both.  The  records 
in  each  user  substructure  are  organized  to  allow  hierarchical  grouping  of 
files  for  the  user.  At  the  lowest  level,  there  is  a  file  description  for 
each  file  in  which  is  kept:  information  to  allow  mapping  from  file  to 
source  location;  specifications  by  file  creator;  counts  of  jobs  currently 
using  the  file;  the  information  recorded  by  FMS  about  the  file.  At  the 
highest  level  in  the  user  substructure,  there  is  a  User  Master  Catalogue 
(UMC)  that  indexes  the  substructure  for  the  user.  Where  there  are  sub¬ 
ordinate  catalogues,  the  UMC  indexes  each  file  description.  When  there 
are  subordinate  catalogues,  the  UMC  indexes  catalogues  as  well  as  file 
descriptions  immediately  subordinate  to  the  UMC. 
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b.  Control  of  Storage  Space 

Although  the  File  Management  Supervisor  does  not  specifically 
manage  storage  space,  as  it  is  managed  by  a  space  allocator  in  the  GCOS 
section,  FMS  does  accept  and  obey  limits  on  space  to  be  used  for  both 
default  and  overriding  specifications  on  devices  to  use.  FMS  obtains 
space  for  files  to  be  created  and  releases  space  for  files  to  be  deleted 
on  fixed  devices  and  on  removable  structured  disc  packs  that  are  mounted 
at  the  time  of  the  create  or  delete  request.  If  enough  space  for  creation 
is  not  available,  the  request  is  denied.  If  the  request  is  for  growth, 
growth  is  constrained  to  the  named  device,  or,  if  not  named,  to  the 
remaining  device  of  the  same  type  with  space  proportional  to  the  current 
size  of  the  file  to  be  expanded.  When  the  file  is  created  or  grown  sub¬ 
ordinate  to  a  catalogue  on  a  removable  structured  disc  pack,  however, 
space  is  obtained  only  from  that  disc  pack  either  for  file  create,  or 
file  growth.  Without  such  a  constraint,  the  ability  to  move  a  file  from 
off-line  to  on-line  would  be  lost  since  mounting  instructions  are  issued 
only  for  a  single  pack;  the  mounted  pack  cannot  be  dismounted  since  it 
contains  the  file  description.  The  smallest  allocation  possible  is  one 
Honeywell  defined  "11  ink",  which  is  320  words,  1  ,280  9-bit  bytes,  or 
1,260  six-bit  characters.  Other  allocation  units  are  integer  multiples 
of  llinks  of  1,  2,  4,  6,  12,  24,  36,  48,  or  60. 

c.  Protection  Against  Unauthorized  Access 

Unauthorized  usage  of  a  catalogued  file  is  prevented  by  means 
of  passwords,  permissions,  and  security  locks.  A  password  must  be  speci¬ 
fied  for  each  user  at  the  time  a  System  Master  Catalogue  entry  is  prepared. 
Passwords  can  optionally  be  specified  for  catalogues  and  files.  User 
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passwords,  to  permit  reference  of  catalogue  files,  or  to  use  the  Time¬ 
sharing  System,  contain  one  to  twelve  combinations  of  alpha-numeric 
characters,  dashes,  or  periods.  These  are  requested,  in  the  Time¬ 
sharing  System,  whenever  a  user  requests  admittance  to  the  system  pre¬ 
senting  his  individual  name  first.  A  strikeover  mask  is  provided  to 
prevent  the  password  from  being  visible.  Timed  passwords  are  also 
employed  for  files  or  catalogues. 

When  a  file  or  catalogue  is  created  or  modified,  the  creator 
or  modifier  can  specify  what  actions  are  permitted  on  the  file,  catalogue, 
or  subordinate  files  or  catalogues  by  what  users.  Both  general  and  speci¬ 
fic  permissions  can  be  specified  for  a  catalogue  to  apply  to  subordinate 
files  or  catalogues.  Permissions  can  be  specified  by  anyone,  in  general, 
or  for  specifically  named  users.  When  there  are  several  levels  of  sub¬ 
ordination,  the  permissions  at  each  level  are  accumulated.  Permitted 
actions  include  Read,  Write,  Append,  Execute,  Modify,  and  Purge.  If  a 
request  is  received  that  requires  a  permission,  the  permission  field  is 
searched  for  general  permissions  first,  then  specific  permissions,  and 
then  exclusions.  Only  the  creator  of  a  file  is  considered  to  have 
exclusive  permission  for  that  file's  use. 

A  file  can  be  security  locked  to  limit  allocation  of  the  file. 
Security  locking  of  a  catalogue  limits  allocation  of  any  files  subordinate 
to  the  catalogue.  Allocation  is  denied  to  a  security  locked  file  if  the 
request  for  allocation  is  from  anyone  but  a  user  with  LOCK  permission,  or 
the  creator  of  the  file.  If  a  catalogue  is  security  locked,  any  file 
subordinate  to  the  catalogue  cannot  be  allocated  except  to  users  who 
have  LOCK  permission  for,  or  are  the  creators  of,  the  file.  Security 
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locking  is  performed  by  a  catalogue  operation  similar  to  file  creation  or 
file  modification.  It  can  only  be  performed  by  a  user  who  is  the  creator 

or  has  LOCK  permission  for  the  file  or  catalogue  being  locked.  Similarly, 

removal  of  a  security  lock  is  performed  by  a  catalogue  operation  that 
can  only  be  performed  by  a  user  who  is  the  creator  or  has  LOCK  permission 
for  the  file  or  catalogue  being  unlocked. 

d.  Protection  Against  Device  Failure 

Six  facilities  provide  differing  degrees  of  protection  against 
common  forms  of  device  failure.  Either  files  or  catalogues,  or  both,  can 
be  protected:  Verifying  file  writes  may  prevent  data  from  being  written 
to  device  space  from  which  it  cannot  be  subsequently  read;  duplicating  a 
file  permits  immediate  receovery  if  one  or  more  pages  of  a  file  on  a 

device  are  unreadable,  but  the  recovery  time  is  not  as  quick  as  it  is  from 

verification;  journaling  file  changes  permits  recovery  if  one  or  more 
pages  of  a  file  on  a  device  are  unreadable,  recovery  time  is  still  not 
as  quick  as  from  duplication;  saving  a  file  permits  recovery  of  the  entire 
file,  unlike  duplication  or  journaling,  the  entire  file  must  be  restored, 
since  restoration  provides  the  version  of  the  file  at  the  time  of  the 
save,  the  file  is  generally  out-of-date  at  the  time  of  th.e  recovery. 
Duplicating  catalogues  permits  immediate  recovery  if  a  catalogue  is 
unreadable,  duplication  of  catalogues  limits  the  number  of  files  that 
require  restoring  to  those  contained  on  the  failed  device;  saving  of 
catalogues  permits  recovery  of  an  unreadable  catalogue,  but  recovery 
time  is  not  as  quick  as  it  is  from  duplication,  restoring  from  a  catalogue 
save  requires  all  catalogues  and  all  files  referenced  from  the  catalogues 
be  restored,  restoring  generally  provides  out-of-date  versions  of  the 


catalogues  as  well  as  the  files. 

e.  Protection  Against  Improper  Update 

The  File  Management  Supervisor  cannot  protect  against  many 
possible  causes  of  a  file  being  improperly  updated  since  this  would 
require  not  only  FMS  knowledge  of  the  file  format,  but  also  knowledge  of 
the  file  application  itself.  However,  there  are  two  causes  of  improper 
file  update  that  FMS  can  provide  protection  against.  First,  when  a  job 
that  is  updating  a  file  terminates  abruptly,  either  because  of  job  or 
system  failure,  the  file  is  left  in  a  partially  updated  condition.  FMS 
is  able  to  cancel  these  partial  updates.  Second,  for  new  application 
programs  that  have  been  inadequately  tested,  FMS  provides  a  way  for 
testing  programs  against  the  production  file  without  any  danger  of  damage 
to  the  file. 

f.  Protection  Against  Concurrent  Usage 

One  of  the  four  available  access  options  must  be  selected  for 
controlling  concurrent  allocations  to  a  file.  The  default  option  is  the 
NORMAL  operation  which  allows  either  multiple  readers  or  a  single  writer. 
With  this  option,  no  interference  of  one  job  with  another  concurrently 
allocated  can  occur  since  only  concurrent  readers  are  allowed.  Two 
other  options,  CONCURRENT,  and  MONITOR,  allow  both  multiple  readers  and 
multiple  writers  to  be  allocated  at  the  same  time.  With  MONITOR,  reads 
and  writes  to  the  file  are  controlled  so  that  any  that  might  interfere 
with  the  operation  of  another  job  are  either  prevented  or  delayed  until 
the  chance  of  interference  is  past.  With  CONCURRENT,  however,  no  such 
control  over  reads  and  writes  is  exercised  by  the  File  Management  System. 
The  chance  of  interference  of  one  job  with  another  must  be  tolerated, 
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controlled  by  other  means  such  as  programming  within  each  job  or  in  a 
common  file  content  manager,  or  at  least  controlled  enough  to  decrease 
the  chance  or  types  of  interference  to  a  tolerable  extent.  One  final 
option,  READ  WHILE  WRITE,  allows  multiple  readers  and  a  single  writer. 

The  writer  may  interfere  with  the  operation  of  the  readers,  but  since 
only  a  single  writer  is  allowed,  interference  between  writers  which  might 
damage  the  file  content  cannot  occur,  and,  of  course,  readers  cannot 
interfere  at  any  time  with  the  operation  of  the  writer. 

I.  INCORPORATING  ADDITIONS  TO  MINSY:s  MIS 

Any  management  information  system  that  remains  static  and  merely 
provides  information  to  users  that  support  existing  methods  of  operation 
is  not  being  used  to  its  full  potential.  Managers  of  a  system  such  as 
the  Shipyard  Management  Information  System  at  Mare  Island  Naval  Shipyard 
must  seek  out  user  problems  to  determine  whether  or  not  the  development 
of  new  managerial  systems  together  with  supporting  information  system 
data  and  reports  is  needed  and  can  be  cost-effective.  Two  examples 
follow  which  demonstrate  how  this  has  been  done  at  MINSY.  A  summary  of 
procedures  utilized  at  Mare  Island  for  local  system  improvements  is  also 
included. 

1.  WOJO 

One  of  the  persistent  problems  which  has  prevented  effective 
shipyard  planning  and  production  control  has  been  the  failure  to  integrate 
all  planning  and  estimating,  design  scheduling,  and  material  ordering 
functions  of  an  availability  in  one  production-oriented  work  package. 

WOJO,  or  the  Work  Oriented  Job  Order  System,  is  an  integrated  planning 
methodology  for  developing,  managing,  and  controlling  industrially 
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oriented  work  packages  for  shipyard  repairs  and  alterations  during 
overhauls,  conversions,  and  new  construction  [19],  Under  WOJO,  work  is 
planned  and  packaged  in  the  manner  in  which  it  is  to  be  accomplished  by 
the  various  shops.  This  is  actually  done  on  a  system  or  area  basis  such 
that  a  single  Job  Order  issued  to  a  shop  for  accomplishment  may  be 
composed  of  repair  items,  SHIPALTS,  ORDALTS,  and  special  project  tasks 
all  considered  to  be  one  job. 

WOJO  requires  that  shipyard  planning  and  scheduling  activities 
for  an  availability  be  coordinated  and  integrated  during  the  work  scoping 
period.  As  defined  by  WOJO,  work  scoping  requires  all  availability  plan¬ 
ning  inputs  (design  plans,  planning  and  estimating,  material  ordering) 
to  be  specified,  scheduled,  and  monitored  as  a  whole  -  not  as  individual 
functional  items.  Accordingly,  WOJO  requires  active  participation  from 
Design,  Planning  and  Estimating,  Scheduling,  and  Supply  Department 
personnel,  as  well  as  representatives  from  other  specialized  shipyard 
organizational  elements  such  as  Combat  Systems  and  Nuclear  Power  on  an 
ad-hoc  basis.  The  WOJO  system  is  employed  for  those  ships  where  much 
of  the  work  on  a  system,  or  in  a  single  location  on  board  the  ship, 
involves  several  closely  related  customer  work  requests  that  can  best  be 
accomplished  as  a  single  integrated  effort  by  the  work  force. 

Twelve  MIS  transaction  codes  are  required  to  enter  WOJO  inputs  to 
the  Shipyard  MIS.  These  are  input  from  three  source  documents:  the 
Industrial/Financial  Control  Transmittal  Sheet  is  the  primary  document, 
the  Work  Estimate  Sheet  and  the  Job  Order  Document  are  secondary  inputs. 
Data  entries  must  be  complete  and  accurate  in  order  to  ensure  that 
reliable  data  are  recorded  in  the  pertinent  MIS  files  and  are  subsequently 
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reflected  in  the  MIS  output  reports.  The  Industrial/Financial  Control 
Transmittal  Sheets  are  prepared  fay  the  lead  planner  who  enters  approved 
KEYOPS,  man-hour  cost  estimates,  scheduled  dates,  material  cost  estimates, 
and  percentage  prorations/translations  as  they  are  applicable  to  the 
various  shops  scheduled  to  perform  the  integrated  effort.  The  Work 
Oriented  Job  Order  System  outputs  are  reflected  in  the  Shipyard  Manage¬ 
ment  Information  System  Financial  Subsystem.  Nine  reports  are  affected 
by  WOJO  transactions.  These  reports  include  items  concerning  proration/ 
translation  percentages  for  charge-back  procedures,  man-hour  allowances, 
a  record  of  all  such  transactions,  distribution  percentage  changes,  and 
cost  control . 

2 .  Ship  Work  Control  System 

The  Ship  Work  Control  System  (SWCS)  is  a  computer-based  system 
for  maintaining  listings  of  all  outstanding  and  completed  non-nuclear 
deficiencies,  test  documents,  work  authorized  by  the  work  permit  system 
and  other  miscellaneous  documents  or  certifications  for  each  ship  under¬ 
going  overhaul  or  repair  at  Mare  Island  Naval  Shipyard  [20].  The  SWCS 
upgrades  the  former  Non-Nuclear  Composite  system,  see  reference  21,  to  an 
on-line  system  of  direct  computer  entry  and  retrieval.  This  on-line  system 
utilizes  remote  terminals  to  gain  entry  to  the  data  base  where  information 
is  stored.  The  access  for  retrieval  of  information  is  through  a  set  of 
standardized  codings  available  in  detail  in  reference  20. 

The  Ship  Work  Control  System  is  managed  by  the  Ship  Work  Control 
Center  (Code  356)  to  provide,  on  demand,  convenient  locally  generated 
management  reports  to  assess  the  status  of  remaining  work  on  non-nuclear 
shipboard  systems.  SWCS  is  a  production-oriented  system  which  keeps 
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track  of  the  numbers  of  various  types  of  source  documents  outstanding  on 
a  given  ship.  These  source  documents  are  each  a  source  of  some  kind  of 
shipyard  action  on  the  system  involved.  Each  source  document  is  assigned 
to  a  responsible  code,  to  the  shop  supervisor  level,  for  action.  It  is 
additionally  identified  by  a  unique  report  number,  Key  Event,  compartment, 
deck,  and  location.  SWCS  contains  a  strong  inherent  managerial  account¬ 
ability  and  control  device  in  its  requirement  for  Shop  Supervisors  to 
verify  completion  of  the  action  called  for  by  a  given  source  document, 
and  to  sign  the  Code  356  copy  of  that  document  before  the  document  can  be 
cleared  from  the  computerized  system  reports.  This  requirement,  self- 
imposed  by  MINSY,  serves  to  increase  supervisory  involvement,  knowledge, 
and  accountability  for  work  status  determination  and  lends  considerable 
credibility  to  SWCS  reports. 

a.  SWCS  Terminal  Operations 

To  provide  the  on-line  capability,  remote  terminals,  which 
are  directly  connected  to  the  computer  via  telephone  line,  are  spotted 
at  various  locations  throughout  the  shipyard,  see  figure  16.  These 
terminals  contain  a  cathode  ray  tube  for  message  display,  a  keyboard  for 
data  input  and  data  base  inquiry,  and  an  eighty  character  wide  printer 
capable  of  printing  data  which  is  sent  to  the  terminal.  These  terminals 
allow  for  instant  inquiry  of  the  status  of  items  on  the  data  base.  To 
provide  for  large  volume  reports,  the  Ship  Work  Control  Center  is  equipped 
with  a  132  character,  300  lines  per  minute  printer,  and  a  XEROX  7000  Com¬ 
puter  Forms  Feeder  which  provides  for  the  printing  jf  large  volume  132 
character-wide  reports  and  their  subsequent  reductions  to  8  x  10  1/2  inch 
size  paper. 
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Figure  16 


SWCS  TERMINAL  LOCATIONS 


Code 

Assignment 

Bldg/ 

Floor 

Termi nal 
Number 

Function/Locati on 

100 

521/1 

23 

Code  100  Conference  Room 

1069 

113 

229/2 

1,  25,  27 

Data  Processing  Office 

133.11 

45/2 

16 

Non-Nuclear  Inspection 
Division  Records  Center 

191.2 

55/2 

t 

15 

Combat  System  Test  Divi¬ 
sion 

280.48/365 

742/2 

19 

Ocean  Engineering  Test 

Center 

290.1 

69/2 

14 

HP&A  Test  Operation  Branch 

330 

108/2 

6 

Drydock  #1  Ship  Supt. 

Office 

330/365 

Barge 

YRR63 

7 

Ship  Superintendent  Office 

330/365 

69/1 

8 

Berth  9  Ship  SuDt.  Office 

330 

163/2 

9 

Berth  7/8  Ship  Supt.  Office 

330/365 

Barge 

YC-1449 

10 

Ship  Superintendent  Office 

365 

163/1 

11 

Berth  7/8  SWCC  Satellite 
Office 

330/365 

664A 

12 

Berths  17/18/19  Ship  Supt./ 
SWCC  Satellite  Office 

330 

69/2 

18 

Repair  Officer  Conf.  Room 

330/365 

BAB 

22 

Drydock  #3  Ship  Supt. /SWCC 
Satellite  Office 

365.1 

69/2 

2,  3,  4,  5 
&  26 

Ship  Work  Control  Branch 

Main  Record  Center 

920/956 

46 

20 

Code  956  Office  Area 

930/938 

128 

21 

Code  930.44  Shop  Planning 
Office  (938  Planners) 

938TCC 

69/1 

17 

938  Shop  Test  Control 

Center 

950 

866 

13 

_ 

Code  950.4  Planning  Office 

b.  DATANET  355 

The  DATANET  355  Front-End  Network  Processor  (FNP)  is  a  Honey¬ 
well  provided  high  performance,  stored-program  FNP  designed  to  match  the 
large-volume  communication  needs  of  the  6060  multidimensional  information 
system  in  general  and  the  requirements  of  the  Mare  Island  Naval  Shipyard 
Ship  Work  Control  System  in  particular.  It  features  total  integrated 
circuit  logic  construction  and  a  memory  size  of  sixteen  or  thirty-two 
thousand  words  on  a  memory  cycle  of  one  micro-second.  DATANET  can  accom¬ 
modate  data  of  variable  word  lengths  of  six,  nine,  eighteen,  or  thirty- 
six  bits.  All  data  words  are  individually  addressable  to  allow  highly 
efficient  processing  of  tabular  data.  Ninety-eight  instructions  in  an 
eighteen  bit  format  are  provided  with  one  single-address  instruction  per 
word.  Three  index  registers  and  multilevel  indirect  addressing,  with 
indexing  at  all  levels,  give  an  addressable  storage  to  thirty-two 
thousand  words. 

The  system  organization  of  the  DATANET  355  FNP  follows  the 
pattern  of  the  6060.  It  is  a  storage-oriented  computer  with  its  own 
independent  memory,  processor,  and  input/output  modules,  see  figure  17. 
These  three  basic  modules  are  independently  timed  and  operate  asynchro¬ 
nously  with  each  other.  The  processor  and  the  I/O  Controller,  the  active 
units,  process  data  at  their  own  rates  and  erquest  cycles  from  storage 
modules,  passive  units,  as  the  need  arises.  Only  when  the  processor 
executes  certain  input/output  instructions  must  the  processor  and  the 
Input/Output  Controller  communicate  with  each  other. 

Input/Output  is  designed  to  facilitate  efficient  real-time 
concurrent  servicing  of  multiple  terminals  and  peripheral  devices.  Up 
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Figure  17  DATANET  355  FRONT-END  PROCESSOR 
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OR  PRINTER- _  COMMON  PERIPHERAL 

^  ADAPTER 


to  sixteen  adapters  can  be  provided  to  accommodate  a  total  data  transfer 
rate  of  up  to  500,000  words  per  second  (with  six  to  thirty-six  bits  oer 
word).  Sixteen  levels  of  priority  interrupt,  with  sixteen  sublevels  per 
level  and  corresponding  interrupt  masks,  are  provided.  As  a  module  of 
the  6060  system,  OATANET  is  capable  of  simultaneously  handling  uo  to  two- 
hundred  teleprinter,  or  thirty-two  remote  batch  users,  or  thirty-two  CRT 
subsystems  or  an  appropriate  mix  of  the  three  classes. 

3.  MINSY  MIS  Improvements 

The  Director  of  Management  Engineering  (Code  140)  at  Mare  Island 
Naval  Shipyard  serves  as  the  focal  point  for  Shipyard  MIS  matters  includ¬ 
ing  performance  of  special  studies  and  projects  in  the  fields  of  manage¬ 
ment  information  systems  and  related  automatic  data  processing  system 
requirements  [17].  Code  140  coordinates  requests  for  improvements  to 
the  Shipyard  MIS,  as  they  may  related  to  the  total  shipyard  complex,  with 
the  Data  Processing  Office  and  forwards  the  required  information  to  CASD0 
and  NAVSEA  in  accordance  with  NAVSEA  directives.  The  Director  of  Manage¬ 
ment  Engineering  also  serves  as  shipyard  liaison  with  CASD0  and  NAVSEA 
073  as  required  to  accomplish  approved  Shipyard  MIS  requirements  [2]. 

On  the  local,  MINSY,  level,  Code  140:  assists  local  depart¬ 
ment  heads  in  determining  suitable  methods  for  satisfying  departmental 
informational  requirements;  audits  the  installed  MIS  as  necessary  to 
assure  that  it  is  serving  its  designed  purpose  and  is  operating  effectively; 
annually  reviews  distribution  and  use  of  all  ADP  reports  to  ensure  minimal 
distribution  consistent  wi th  local  departmental  information  requirements; 
reviews  proposed  local  ADP  reports,  additions  or  modifications  to  the 
Shipyard  MIS  for  necessity  and  to  determine  the  optimum  means  of  satisfying 
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requirements  involved  in  order  to  obtain  maximum  cost-effectiveness  ^or 
both  the  affected  department  and  the  Data  Processing  Office. 

When  requesting  local  programmer  or  data  processing  services 
requiring:  the  development  of  a  new  data  system,  the  modification  of  an 
existing  system,  other  than  correction  of  program  deficiencies;  or  the 
generation  of  new  or  modified  reports  from  the  existing  system,  the 
cognizant  department  head  is  to  provide  the  Director  of  Management 
Engineering  a  cost/benefit  analysis.  A  feasibility  study  will  be 
prepared  using  Code  140  and  the  requesting  department's  personnel, 
recognizing  that  the  Shipyard  Management  Information  System's  develoo- 
ment,  implementation,  and  monitoring  are  under  technical  and  coordina¬ 
tion  control  of  the  Director  of  Management  Engineering, 

Modification  requests  must  state  specifically  what  the  prooosed 
revision  is  expected  to  accomplish  along  with  the  benefits,  including 
dollar  cost  savings,  and  relate  this  to  an  established  functional  or 
organizational  responsibility.  Cost  savings  can  be  of  three  types: 
direct  savings  resulting  from  the  computer  performing  tasks  that  are 
currently  done  manually,  or  a  new  reauirement  that  is  cheaper  to  perform 
under  ADP  as  opposed  to  manually,  this  type  of  saving  is  the  best  justi¬ 
fication  providing  there  is  a  genuine  need  for  the  generated  output; 
indirect  savings  result  from  productivity  improvement  as  a  result  of  the 
use  of  additional  or  more  timely  data;  and  intangible  benefits  which 
improve  morale  or  work  quality  that  cannot  usually  be  quantified.  The 
requests  must  also  include  anticipated  problems  and  recommendations  for 
the  resolution  of  those  problems.  Lastly,  organizational  charts  delineat¬ 
ing  the  decision  points  to  be  satisfied  by  the  proposed  modification  in 
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relationship  to  the  cost/benefits  of  the  present  methods  must  also  be 
included.  It  is  with  this  whole  spectrum  of  requirements  (paperwork) 
that  only  those  modification  proposals  that  will  genuinely  benefit  the 
Shipyard  MIS  will  be  initiated. 

J.  PHYSICAL  SECURITY 

Since  Security  of  the  internal  computer  data  base  was  adequately  dis¬ 
cussed  under  the  Data  Base  Manager  section  of  this  chapter,  this  section 
will  address  physical  security  precautions  implemented  for  protection  of 
the  data  base  and  the  data  processing  equipment  in  the  Data  Processing 
Center  at  Mare  Island  naval  Shipyard.  The  center  is  manned  twenty-four- 
hours-a-day,  seven-days-a-week  every  week  of  the  year  with  the  exception 
of  Thanksgiving  and  Christmas  Days.  When  the  center  is  not  manned,  motion 
and  temperature  alarms  are  activated  to  monitor  unauthorized  activity. 

Each  member  of  the  data  processing  staff  is  known  by  sight  by  every  other 
member  of  the  staff.  Report  disssemi nation  from  the  DP  Center  is  care¬ 
fully  controlled  in  that  only  authorized  guard-mail  or  messenger  personnel 
from  the  affected  departments  are  allowed  to  remove  outputs  from  the 
center. 

Terminal  security  is  provided  by  the  previously  mentioned  password 
system,  which  is  changed  periodically,  and  the  security  "kernal"  methods 
alluded  to  that  are  resident  within  the  operating  system.  Security  of 
each  terminal  is  also  provided  by  each  location  within  which  a  terminal 
resides.  A  time  lockout  system  for  terminals  has  been  suggested  but  not 
yet  implemented.  The  highest  Department  of  Defense  level  of  information 
contained  within  the  system  is  "Confidential",  Annual,  and  as  requested, 
security  inspections  of  the  system  are  also  provided  by  the  Security 
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Department.  Mare  Island  Naval  Shipyard  itself  also  provides  overall 
security  in  the  form  of  a  contingent  of  United  States  Marine  Corps  per¬ 
sonnel  stationed  at  M I  NS V  and  a  Mare  Island  Police  Force.  Fire  protection 
is  provided  by  smoke  and  heat  alarms.  A  "wet"  fire  suppressant  system 
is  installed  with  plans  to  implement  a  halogen-based  system  in  the  future. 
There  is  only  one  entrance  to  the  computer  and  data  storage  room,  which 
is  secured  by  a  cypher  lock  system.  The  data  storage  room  is  separated 
from  the  computer  room  by  a  heavy  steel  door.  Finally,  the  building  itself 
is  an  innocuous  appearing  structure  with  no  signs  labeling  it  as  a  data 
processing  site.  There  are  no  windows  in  the  computer  equipment  or  storage 
rooms  which  are  further  separated  from  the  outside  world  by  two  fire 
doors  in  addition  to  the  cypher  door  access. 


IV.  DISTRIBUTED  DATA  PROCESSING  AT 


MARE  ISLAND  NAVAL  SHIPYARD 


A.  INTRODUCTION 

It  is  recognized  that  distributed  data  processing  as  defined  in 
chapter  I  does  not  currently  exist  at  Mare  Island  Naval  Shipyard.  What 
does  exist  is  a  front-end  network  processor,  the  DATANET  355.  The  use  of 
a  front-end  communications  processor  associated  with  a  large  computer  is 
an  accepted  practice  in  modern  data  processing.  Few  large-scale  systems 
do  not  rely  on  data  communications  to  serve  at  least  some  of  their  uses. 
While  some  large  corporations  have  instituted  a  policy  of  using  large 
minicomputers  and  medium-scale  computers  rather  than  large  computers  to 
meet  all  corporate  distributed  data  processing  needs,  most  corporations 
have  preferred  to  build  outward  from  a  well-established  central  computing 
facility.  This  approach  to  DDP  may  not  be  bold,  but  it  is  sensible.  By 
retaining  the  large  systems,  users  protect  the  investment  that  has  been 
made  in  software,  and  especially  since  the  price  wars  of  the  spring  of 
1977,  they  can  point  to  dramatic  price  decreases  of  large  system  hardware 
as  justification. 

The  large  systems  role  in  distributed  processing  may  be  any  combination 
of  the  following:  host  to  a  time-sharing  network-,  guardian  of  the  cor¬ 
porate  data  base;  as  a  computational  resource  for  research  and  development 
users;  and,  host  to  a  mammoth  batch  processing  system.  If  these  cate¬ 
gories  do  not  sound  exactly  like  distributed  processing,  it  must  be 
remembered  that  the  work  accomplished  in  a  DDP  system  is  basically  no 
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different  from  that  which  was  done  before  distributed  processing  -  it 
is  the  execution  mode  that  is  different.  For  most  users,  the  preferred 
approach  to  distributed  processing  is  to  follow  a  hierarchical  scheme, 
with  the  large  system  as  the  pinnacle  of  a  mountain  of  smaller  comouters 
and  terminals.  The  large  system  has  the  ability  to  construct  the  complete 
corporate  picture  from  the  jigsaw  of  divisional  and  departmental  pieces. 
This  is  the  direction  that  this  section  of  the  presentation  will  follow. 

It  will  be  shown  how  an  effective  distributed  data  processing  system  can 
be  created  from  selective  addition  of  equipment  to  the  data  processing 
configuration  currently  employed  at  Mare  Island  flaval  Shipyard. 

B.  PROBLEMS  WITH  THE  CURRENT  SHIPYARD  MIS 

The  standard  Shipyard  Management  Information  System  as  implemented  at 
Mare  Island  Naval  Shipyard  contains  a  proven  set  of  programs  that  five  of 
the  eight  members  of  the  Naval  Shipyard  Complex  have  used  for  thirteen 
years.  The  other  three  shipyards  have  utilized  this  version  of  the  Ship¬ 
yard  MIS  for  five  years.  However,  there  are  some  shortcomings  to  the 
system,  some  relatively  minor,  others  of  a  more  serious  nature,  that  can 
be  readily  recognized. 

1 .  Programs 

Current  application  programs  are  designed  specifically  within  the 
constraints  of  the  second  generation  equipment  employed  in  the  shipyard 
complex  prior  to  the  acquisition  of  the  Honeywell  6060  equipment.  These 
applications  are  rigidly  structured  with  data  that  is  intended  for  use 
within  the  Shipyard  MIS  processed  in  a  batch  oriented  manner.  Since  each 
application  area  within  the  Shipyard  MIS  normally  requires  several  files 
to  fulfill  its  mission,  application  maintenance  costs  are  relatively  high. 
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As  a  result;  the  data  that  is  provided  to  the  various  users  is  somewhat 
behind  the  normal  business  cycle.  The  user  does  not  have  direct  access 
to  his  data  once  it  has  been  submitted  to  the  Data  Processing  Office  for 
inclusion  in  the  Shipyard  MIS;  he  must  wait  for  that  office  to  provide 
him  with  a  printed  report  to  be  delivered  at  some  future  time.  Also, 
the  same  data  may  be  found  incorporated  into  multiple  applications  wherever 
it  is  used. 

2.  Internal  Reports 

One  of  the  concepts  of  a  Shipyard  Management  Information  System, 
as  mentioned  in  chapter  II,  concerned  the  grouping  of  similar  reports  into 
report  families  based  on  the  manner  in  which  information  is  sorted.  The 
major  difference  to  be  found  within  a  report  family  center  around  whether 
the  information  is  sorteo  by  ship,  by  shop,  or  by  work  center.  As  an 
example,  the  PF-102A  (Daily  Force  Distribution  Report,  Summary)  and  the 
PF-102B  (Daily  Force  Distribution  Report,  Ship  by  Shift)  reports  are  both 
generated  from  the  Workload  Forecasting  Application  within  the  Industrial 
Subsystem  of  the  Shipyard  MIS.  The  block  diagram  of  the  generation  for 
those  reports  was  presented  in  figures  12  and  13.  As  can  be  seen,  these 
reports  utilize  the  same  inputs,  same  sorts,  same  control  and  verifica¬ 
tion  programs,  and  same  editing  procedure.  The  only  difference  is  that 
the  PF-102B  report  will  provide  data  concerning  the  total  number  of  man- 
days  expended  for  waterfront  work  per  overhaul  type,  while  the  PF-102A 
report  does  not  directly  differentiate  v/aterfront  from  other  productive 
applications.  It  would  be  a  relatively  simple  matter  to  provide  another 
horizontal  row  for  the  PF-102A  report  in  which  waterfront  information  for 
each  shop  was  presented,  thus  eliminating  one  redundant  report.  Similar 
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examples  of  redundant  reports  abound  throughout  the  Shipyard  MIS  report 
structure. 

3.  Additional  Application  Requirements 

Expansion  of  the  Shipyard  MIS  to  include  features  for  Quality 
Assurance,  tool  control,  and  material  process  control  need  to  be  imple¬ 
mented  as  discussed  in  chapter  II.  Inclusion  of  a  Quality  Assurance 
Application  within  the  Industrial  Subsystem  would  reduce  this  manual  data- 
handling  burden  supporte  dby  shipyard  personnel.  A  completely  automated 
inventory  and  control  system  for  expensive  and  portable  (pilferable) 
hand  tools  utilized  in  nuclear  work  would  assist  in  the  reduction  of  tool 
"loss"  and  allow  some  of  the  budget  currently  designated  for  tool  replace¬ 
ment  to  be  deployed  elsewhere.  The  application  could  be  entitled  "Tool 
Control"  and  be  placed  within  the  Material  Subsystem  of  the  Shipyard  MIS. 

A  material  process  report  program  should  be  included  within  the  Industrial 
Material  Application  which  updates  direct  material  item  transactions  not 
only  upon  receipt  of  materia;  but  whenever  the  location  status  of  DMI 
material  changes. 

4.  Greater  Capabilities 

A  need  exists  to  achieve  greater  capabilities  from  the  Shipyard 
Management  Information  System.  Some  of  those  additional  capabilities 
are:  the  ability  to  obtain  immediate  projections  as  to  the  impacts  of 
an  overhaul  schedule  change  on  production  schedules,  manpower  require¬ 
ments  and  availability,  and  on  facility  loading;  automated  print-out  of 
job  order  and  KEYOP  instructions,  material  staging  lists,  and  job  material 
lists  at  the  point  of  use  and  time  of  need;  continual  on-line  status  for 
all  shop  store  and  direct  material  items  that  are  on  order,  in  stock,  or 
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being  inspected;  on-line  expenditure  and  orogress  data  for  any  ship  avail¬ 
ability  at  the  job  order,  KEYOP,  and/or  summary  level;  automated  retrieval 
of  applicable  historical  data  to  use  for  planning  of  new  work  and  esti¬ 
mating  the  cost  thereof,  and  for  the  forecasting  of  future  workload;  and 
an  overall  dynamic  shipyard  study  capability. 

5 .  External  Reports 

In  addition  to  needs  that  are  identified  to  serve  the  requirements 
of  management  at  various  levels  within  the  shipyard,  there  has  been  a 
definite  trend  in  increasing  requirements  for  information  on  shipyard 
operations  from  many  levels  within  the  Federal  Government.  Many  of  the 
requirements  are  for  one-time  pieces  of  information;  however,  most  of 
these  one-time  requirements  have  a  habit  of  becoming  continuing  require¬ 
ments  either  for  a  change  in  an  existing  reporting  system  of  for  new 
reports.  No  relief  from  these  trends  for  greater  regulation  from  higher 
authorities  and  for  more  reporting  is  foreseen.  Rather,  the  trend  seems 
to  be  toward  ever-increasing  regulation.  A  database  system  that  is  more 
flexible  than  the  currently  employed  rigid  batch  processing  oriented 
programs  is  needed  to  provide  the  capability  of  easier  response  to  the 
increasing  regulation  and  reporting  schemes  that  are  predicted. 

6.  Time! iness 

Although  data  may  be  delivered  to  the  Data  Processing  Office  early 
in  a  workday,  it  is  commonly  not  available  for  managerial  use  until  some¬ 
time  the  following  workday.  There  are  two  reasons  for  this:  first, 
routine  Shipyard  Management  Information  System  processing  at  Mare  Island 
occurs  on  the  swing  shift  0600-2400} ,  after  the  normal  workday  is  com¬ 
pleted,  this  procedure  helps  to  ensure  that  all  transactions  that  are 
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dedicated  to  updating  a  particular  file  are  present  at  the  time  the  file 
is  updated;  and  second,  guard  mail  or  messenger  pick-up  of  reports  does 
not  occur  until  the  beginning  of  the  next  worday,  this  results  in  an 
inherent  delay  in  transporting  of  reports  from  the  Data  Processing  Office, 
where  they  originate,  to  the  user,  where  they  are  employed.  Although 
many  reports  are  prepared  daily,  others  are  available  less  frequently  - 
weekly,  monthly,  semi-annually  or  annually.  These  latter  reports  are 
usually  of  a  summary  nature  reporting  total  information  of  a  type  that  has 
occurred  since  the  last  similar  report.  However,  managers  still  are  not 
able  to  revidw  overall  summary  information  that  they  may  desire  until 
these  summary  reports  are  normally  available,  unless  they  wish  to  submit 
a  special  request  for  them.  Historical  data,  unless  managers  have  retained 
all  of  their  old  reports  applicable  to  the  information  they  may  desire, 
is  also  not  readily  available  in  the  formats  necessary  to  meet  changing 
demands  from  these  customers. 

C.  DISTRIBUTED  PROCESSING  AND  MIS 

Many  of  the  goals  and  objectives  of  the  Shipyard  Management  Informa¬ 
tion  System  at  Mare  Island  Naval  Shipyard  and  the  goals  and  objectives 
of  a  distributed  data  processing  (DDP)  system  are  directly  related.  In 
general,  the  goal  of  MINSY's  MIS  is  to  provide  operational  and  predictive 
information  to  assist  all  levels  of  shipyard  management  in  the  decision¬ 
making  process.  It  desires  to  provide  information  that  is  accurate  and 
timely,  in  an  easily  understandable  form  that  is  practical,  useful,  and 
meaningful  to  these  shipyard  decision-making  efforts. 

1 .  Scope 

As  events  occur  within  the  Shipyard  Management  Information  System, 
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a  distributed  data  processing  system  is  able  to  process  data  concerning 

various  elements  of  shipyard  operations.  Distributed  data  processing  ' 

i 

systems  may  be  programmed  to  generate  the  wide  variety  of  reports  which 
provide  operational  and  predictive  information  in  either  a  real-time 
format,  as  displayed  on  a  cathode  ray  tube,  or  present  it  in  hard  copy, 
depending  on  managerial  requirements.  Distributed  data  processing  sys¬ 
tems  are  able  to  take  into  consideration  many  aspects  of  any  industrial  j 

type  of  activity  which  depends  upon  the  cycle  of  forecasting,  planning, 
scheduling,  production  and  evaluation.  Each  of  these  processes  is  given 
its  processing  priority  and  logical  position  within  the  distributed  system 
by  virtue  of  the  employment  and  type  of  equipment  available  at  each 
processing  note.  Feedback  requirements  of  the  Shipyard  MIS  are  provided 
by  virtue  of  the  OOP  link  communications  capabilities.  A  distributed  data 
processing  system  is  able  to  provide  the  basic  tools  necessary  to  manage 
shipyard  operations  with  as  great,  or  even  greater,  efficiency  than  that 
provided  by  the  current  Shipyard  Management  Information  System. 

2.  Concepts 

Several  of  the  concepts  upon  which  the  Shipyard  Management  Infor¬ 
mation  System  at  Mare  Island  Naval  Shipyard  is  based  are  readily  imple¬ 
mented  by  a  distributed  data  processing  system.  The  large  volume  of  data 
flow  experienced  within  the  Shipyard  MIS  is  as  promptly  automated  and  con¬ 
trolled  by  a  DDP  system  as  by  any  other  management  information  system. 

Managerial  philosophies  of  the  Department  of  Defense  and  Naval  Sea  Systems 
Command  may  still  be  reflected  in  a  distributed  system.  Since  a  dis¬ 
tributed  data  processing  system  allows  for  on-the-spot  information  format¬ 
ting,  shipyard  managers  are  able  to  design  the  format  of  the  reports  they 
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prefer  to  utilize  at  their  processing  sites,  as  long  as  standardized 
reports  are  still  available  to  the  remainder  of  the  shipyard.  Since 
first-line  supervisors  have  the  primary  responsibi 1 i ty  for  quality 
inputs  under  a  DDP  system,  as  well  as  under  the  Shipyard  MIS,  this  con¬ 
cept  does  not  change.  Local  shipyard  control  of  the  development  of  raw 
data  and  report  frequency  is  retained.  Report  sorting  under  a  DDP  system 
is  essentially  the  same  as  under  any  other  management  information  system. 

3.  Adaptability 

A  management  information  system  is  adaptable  in  that  it  is  able 
to  recognize  and  react  rapidly  to  changes  in  technology  and  customer 
requirements.  A  distributed  processing  system  allows  for  the  upgrading 
of  functions  and  performance  in  small  increments,  with  low  corresponding 
cost,  through  its  extensibility  characteristic.  A  minimum  and  a  maximum 
size  in  conjunction  with  the  number  of  permitted  increments  in  order  to 
achieve  a  future  desired  performance  level  may  be  specified  and  arranged 
for  with  initial  system  design. 

The  reconfiguration  capability  of  a  distributed  data  processing 
system  enhances  this  adaptability  requirement  in  that  the  system  can  be 
dynamically  altered  to  provide  resource  services  directed  toward  satis¬ 
fying  unique  requirements.  Normal  operations  are  not  significantly 
affected  by  virtue  of  these  variations  and  the  system  is  able  to  continue 
to  function  in  its  routine  manner  until  those  dedicated  services  are 
returned  to  network  control.  Since  hardware  to  enhance  processing  is 
apportioned  throughout  the  nodes  of  a  distributed  system,  technological 
innovations  can  be  implemented  at  the  sites  that  are  not  only  most  con¬ 
venient,  but  logically  structured  and  decicated  to  whatever  facet  of 
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processing  the  innovation  purports  to  enhance.  This  method  of  incorpor¬ 
ating  technological  changes  results  in  fewer  disturbances  to  normal  opera¬ 
tions  since  the  entire  processing  system  does  not  have  to  be  shut  down 
in  order  to  install  the  change.  It  is  also  physically  easier,  normally, 
to  implement  a  change  to  a  processing  system  at  a  satellite  node  than 
it  is  at  a  central  processing  facility. 

4.  Integration  of  the  MIS  Functional  Levels 

Integration  of  the  six  levels  of  a  management  information  system 
is  enhanced  by  a  distributed  data  processing  system.  Although  processing 
nodes  may  be  located  at  sites  dedicated  to  any  one  of  the  six  MIS  levels 
of  planning,  forecasting,  control,  modeling,  computing,  or  data  adminis¬ 
tration,  the  network  operating  system  resident  within  the  distributed 
data  processing  system  ensures  that  the  jargons,  techniques  and  data 
employed  by  those  specialists  are  integrated  into  the  total  system  con¬ 
figuration  allowing  for  achievement  of  the  overall  objectives  of  the  Ship¬ 
yard  MIS  in  the  most  expeditious  manner.  Each  functional  level  of  the  MIS 
is  able  to  exploit  the  various  resources  available  at  the  other  functional 
levels  within  the  Shipyard  MIS  through  the  capabilities  of  the  NOS  in 
order  to  attain  their  common  goal. 

5.  Primacy  of  Managerial  Decisions 

Retention  of  the  primacy  of  managerial  decisions  within  the  Ship¬ 
yard  Management  Information  System  is  intensified  in  a  distributed  data 
processing  system.  Information  is  available  to  managerial  personnel  soon 
after  it  is  entered  into  the  system.  Programs  resident  within  the  dis¬ 
tributed  system  may  be  dedicated  to  the  tedious  work  of  data  searching, 
calculating,  information  summarizing  and  data  comparisons.  These 


147 


facilities  of  the  system  will  free  the  decision-makers  to:  make  aporo- 
priate  conclusions  from  the  recognition  of  problem  areas;  generate 
relevant  assumptions;  define  criteria;  and,  evaluate  alternatives.  Those 
processes,  in  turn,  permit  the  same  managers  to  perform  the  creative  work 
of  management,  decision  making.  The  distributed  data  processing  system 
is  a  tool  by  which  managers  would  be  allowed  to  concentrate  on  the  neces¬ 
sary  decision  making  oractices,  not  the  processes  by  which  the  information 
was  presented. 

D.  EQUIPMENT  ACQUISITION 

Regulations  originating  from  Federal  agencies  control  every  phase  of 
a  computer's  life-cycle  in  the  government  -  from  the  initial  planning 
stages,  through  acquisition  of  the  system,  to  the  eventual  disposal  of 
the  unit.  These  regulations  apply  not  only  to  the  actual  computer,  but 
also  to  peripheral  devices  such  as  disc  units  and  terminals.  No  less 
than  one  public  law,  eight  Office  of  Management  and  Budget  circulars, 
forty-four  Federal  Information  and  Processing  Standards,  twenty-eight 
Government  Accounting  Office  reports  and  studies,  and  a  multitude  of 
other  directives  and  regulations  have  been  published  to  guide  the  Federal 
automatic  data  processing  manager  in  the  acquisition  of  general  purpose, 
automatic  data  processing  equipment  (AOPE)  in  the  Navy. 

Without  elaborating  on  the  total  procurement  process,  from  consider¬ 
ing  only  the  volumes  of  regulations  concerned,  it  is  obvious  that  to  simply 
follow  the  rules  of  acquistion  is  a  time-consuming  and  complex  process. 

In  addition  to  the  guidance  provided  from  the  previously  listed  regula¬ 
tions,  each  Federal  agency  has  developed  its  own  implementing  directives 
and  instructions  to  insure  compliance  with  that  multitude  or  rules  and 


regulations.  Often,  rather  than  clarifying  or  attempting  to  sinolify 
procedures,  the  local  agency  regulations  only  serve  to  confuse  and 
come1 ’cate  the  procurement  process.  As  a  result,  many  activities  having 
a  real  requirement  for  a  relatively  minor  piece  of  computer  hardware 
become  confused  and  resentful  when  faced  with  that  tangled  array  of  rules 
and  regulations.  For  a  large  computer  installation  project,  it  is  esti¬ 
mated  that  up  to  four  years  are  required  from  conceot  formulation  until 
the  commencement  of  the  actual  acquisition.  Depending  on  the  complexity 
of  the  system,  an  additional  nine  months  to  two  years  is  then  required 
to  conduct  the  actual  acquisition.  This  results  in  a  total  cycle  time 
of  approximately  five  to  six  years  from  the  concept  formulation  stage 
until  completion  of  the  acquisition.  With  six  to  eight  years  being  the 
generally  accepted  figure  for  the  time  between  successive  computer 
generations,  equipment  is  often  out-of-date  before  a  new  system  becomes 
operational.  A  Honeywell  representati ve  has  estimated  that  the  Federal 
Government  process  takes  four  times  as  long  as  a  civilian  commercial 
procurement.  Peter  F.  McCloskey,  a  former  president  of  the  Computers  and 
Business  Equipment  Manufacture's  Association,  stated  that  the  Federal 
acquisition  process  .  frequently  results  in  procurement  of  technology 
that  is  obsolete  because  of  the  time  it  takes  to  implement  purchase.'' 

One  estimate  has  claimed  that,  in  1977,  sixty-eight  percent  of  the  Depart¬ 
ment  of  Defense  ADPE  inventory  was  obsolete,  as  compared  to  a  thirty-five 
percent  figure  for  private  industry  [22], 

It  is  not  the  purpose  of  this  presentation  to  describe  the  detailed 
procedures  required  for  the  acquisition  of  equipment  required  to  support 
the  implementation  of  a  distributed  data  processing  system  at  Mare  Island 
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Naval  Shipyard.  It  is  acknowledged  that  the  paperwork  and  justifica¬ 
tions  required  for  such  an  acquisition  are  beyond  the  scope  of  the  bas':c 
justifications  oresented:  how  distributed  data  orocessing  suocorts  the 
goals  and  objectives  of  the  Shipyard  MIS;  how  DDP  is  able  to  alleviate 
some  of  the  shortcomings  within  the  Shipyard  MIS:  and,  how  distributed 
data  processing  is  able  to  perform  the  required  management  information 
system  functions  of  the  shipyard  in  an  efficient  and  responsive  manner. 
Much  more  detailed  analyses  would  be  required,  including  cost  specifi¬ 
cations  and  demonstrable  savings,  orior  to  any  consideration  being  gi'.^n 
to  the  acquisition  of  any  of  this  type  of  equipment.  For  purooses  of  this 
presentation,  it  will  be  assumed  that  the  decision  to  "go  distributed" 
has  been  made  by  proper  authority.  It  w'll  also  be  assumed  that  the 
implementation  of  the  distributed  system  is  to  be  accomplished  using 
available  Honeywell  devices,  incorporating  them  in  the  6060  system  cur¬ 
rently  installed  at  Mare  Island  wherever  possible. 

E.  PERSONNEL  PREPARATION 

Most  employees,  including  supervisors  and  managers,  are  reluctant  to 
see  major  changes  made  in  their  departmental  organization  and  work  flow. 
Knowledge  about  an  operation  that  has  been  built  up  over  a  long  time 
period  breeds  familiarity  and  confidence.  Change  brings  the  unknown  and 
associated  apprehension  based  on  a  lack  of  knowledge  and  confidence  in 
that  unknown.  To  avoid  being  unprepared,  and  to  overcome  the  apprehen¬ 
sion  of  personnel,  the  implementation  of  distributed  processing  must  be 
approached  in  a  planned  and  orderly  fashion.  There  are  several  approaches 
available  to  develop  policies  and  prepare  personnel  for,  and  to  improve 
the  acceptance  of,  OOP  within  the  Data  Processing  Office  and  Mare  Island 
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Naval  Shipyard. 

1 .  Education 

An  important  initial  step  is  to  be  certain  that  affected  parties 
within  the  organization  have  the  same  understanding  of  what  distributed 
data  processing  means  and  what  it  can  do  for  the  organi zation.  Often 
customers  and  data  processing  professionals  are  educated  by  a  vendor 
advertisement,  a  news  review  of  limited  scooe,  or  a  biased  magazine 
article.  These  may  have  conveyed  misconceptions  about  DDP  technologies 
and  capabilities  which  may  have  curtailed  its  general  acceptance  and 
make  it  difficult  for  the  individual  to  objectively  evaluate  DDP  use  in 
a  variety  of  different  appl ications.  On  the  other  hand,  different  mis¬ 
conceptions  may  have  given  the  potential  user  unrealistic  expectations 
of  DDP. 

The  best  way  to  eliminate  this  problem  of  misconception  is  to 
educate  all  parties  concerned  with  the  operation  of  the  Data  Processing 
Office.  Any  number  of  educational  methods,  or  combinations  of  methods 
may  be  employed  [23].  These  methods  are  outlined  in  figure  18  with  the 
program,  source,  benefits,  and  disadvantages  of  each  summarized.  The  use 
of  this  awareness  education  in  distributed  data  processing  can  give  all 
attendees  a  common  reference  point.  It  should  not  be  expected,  however, 
that  such  education  will  force  everyone  to  think  alike.  If  most  of  the 
people  that  are  involved  in  the  implementation  of  DDP  have  been  through 
the  same  educational  program,  the  professional  data  processing  staff  is 
able  to  use  that  material  as  a  basic  for  building  its  rationale  for  a 
specific  configuration  to  be  employed  within  the  shipyard. 

In  addition  to  the  basic  orientation  course  provided  to  all 
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interested  parties,  data  processing  professional  staff  members  that  are 
to  be  responsible  for  the  total  implementation  and  operation  of  the 
distributed  processing  system  within  Mare  Island  Naval  Shipyard  will 
require  more  detailed  knowledge  of  DOP  in  general,  and  the  Honeywell 
Information  System  as  it  includes  a  distributed  data  processing  format, 
in  particular.  These  subjects  and  level  of  knowledge  desired  are  sum¬ 
marized  in  figure  19.  In  the  education  of  the  data  processing  staff, 
information  may  have  to  be  sought  from  a  number  of  different  sources  since 
no  one  source  is  capable  of  providing  the  complete  SDhere  of  information 
required.  These  sources  should  be  selected,  used,  and  balanced  to  suit 
the  needs  of  the  staff.  They  include:  professional  seminars;  hardware 
vendor  training;  professional  and  vendor  literature;  visits  to  sites  where 
distributed  processing  is  in  use;  attendance  at  relevant  professional 
conferences;  and,  self-study  materials. 

2.  Database  Administrator 

The  database  administrator  (DBA)  is  an  organization's  leader  in 
the  planning,  design,  development,  implementation,  testing,  documentation, 
operation  and  maintenance  of  the  entire  database  environment.  The 
functional  orientation  of  the  database  administrator  is  usually  character¬ 
ized  as  both  technical  and  administrative  in  nature.  There  is  also  a 
promotional  aspect  inherently  present  in  that  the  DBA  represents  database 
administration  concepts  to  all  participants  and  coordinates  all  database 
activities  among  managers,  analysts,  systems  and  applications  program¬ 
mers,  and,  of  course,  the  users.  Because  database  administration  activ¬ 
ities  often  impact  across  organizational  boundaries,  the  DBA  position 
becomes  sensitive,  and  the  prudent  database  administrator  must  be  shrewd 
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in  discerning  jurisdictional  questions  and  conflicting  mission  require¬ 
ments. 

a.  Database  Adminstration  Concepts 

Database  administration,  by  necessity,  encompasses  all  of 
the  technical  and  managerial  activities  required  for  the  organizing, 
maintaining,  and  directing  of  the  database  environments  [24],  A  data¬ 
base  environment  consits  of  the  database  itself,  which  may  include  non- 
automated  as  well  as  automated  information,  the  database  administrator, 
who  will  actually  manage  this  environment,  the  software  tools  used  in 
database  administration  and  data  processing,  and  the  users  of  the 
database.  The  main  goals  of  database  administration  are  to:  optimize 
usage  of  data  in  a  shared  database  environment;  incorporate  a  systematic 
methodology  for  the  centralized  management  and  control  of  data  resources; 
and,  balance  any  conflicting  objectives  with  respect  to  the  parent  organi¬ 
zation's  mission  and  the  overall  economy  of  information  handling. 

Several  key  requirements  for  effective  database  administration 
exist  as  follows:  senior  management  must  be  strongly  committed  to  the 
concept  and  support  it  fully;  the  database  administration  staff  must  be 
technically  competent;  and,  there  should  be  team  participation  in  the 
database  concept  by  the  DBA,  the  technical  staff,  senior  management,  and 
the  users.  Efficient  database  administration  can  provide  several  signi¬ 
ficant  advantages:  the  actual  database  can  be  better  managed  especially 
in  the  context  of  centralization  of  database  control  and  the  sharing  of 
resources;  data  independence  will  be  realized  by  virtue  of  controlled 
definition,  design  and  implementation  of  the  database;  data  redundancy 
and  inconsistency  will  be  reduced  by  the  assessment  and  prioritization  of 
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conflicting  requirements ;  data  integrity  will  be  realized  when  standard¬ 
ization  of  usage  and  enforced  security  regulations  are  employed;  and,  1 

increased  responsiveness  to  the  various  user  communities  can  result 
from  the  better  controlled  and  more  up-to-date  information  that  an 

i 

efficiently  administered  database  will  provide. 

b.  Database  Administrative  Functions 

The  following  list,  although  not  exhaustive,  presents  some 
of  the  basic  functions  of  a  database  administrator.  The  DBA  should  be 
able  to  identify  and  define  common  data  elements.  This  recognition 
needs  to  include  the  relationship  between  data  elements  and  other  com¬ 
ponents  of  the  system  such  as  programs  and  files.  These  conceptual  defi¬ 
nitions  should  be  based  on  a  clear  understanding  of  each  user's  require¬ 
ments  as  well  as  the  needs  of  the  overall  parent  organization.  Whenever 
possible,  the  DBA  needs  to  use  a  data  definition  language  to  define  and 
structure  the  database.  It  is  also  within  the  realm  of  DBA  responsibility 
to  review  and  monitor  data  standards.  Should  the  need  arise  for  dynamic 
alteration  of  the  database,  then  the  DBA  must  initiate  it,  redefining 
the  database,  or  any  part  of  it,  with  a  minimum  of  disruption  and  incon¬ 
venience  to  the  users. 

The  database  integrity  function  is  related  to  the  DBA's  responsi¬ 
bility  for  the  correctness  and  accuracy  contained  within  the  database. 

This  can  be  achieved  through  the  use  of  validation  checks,  stringent 
access  procedures,  periodic  data  dumps,  backup  and  recovery  procedures, 
as  well  as  well-defined  audit  procedures.  The  relationship  between  the 
DBA  and  database  security  is  a  cursory  one.  He  must,  however,  ensure 
that  steps  have  been  taken  to  guard  against  unauthorized  access  to  the 
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database  for  purposes  of  unauthorized  update,  copying,  removal  or 
destruction  of  any  par*  of  the  database.  Often  security  and  integrity 
requirements  are  combined  into  one  software  system  which  will  implement 
procedures  designed  to  simultaneously  perform  both  functions. 

The  database  administrator  must  be  held  responsible  for  the 
continued  well-being  of  the  database.  In  this  capacity,  it  is  his  respon¬ 
sibility  to  maintain  and  update  database  definitions  and  documentation 
including  the  data  element  dictionary.  If  database  performance  monitoring 
and  evaluation  activities  indicate  that  the  database  is  no  longer  effective 
or  efficient  in  its  present  configuration,  then  redefinition,  redesign, 
or  restructuring  activities  may  be  indicated.  It  is  the  responsibility 
of  the  DBA  to  advise  higher  authority  when  this  requirement  manifests 
itself,  and  to  ensure  that  minimum  disruption  of  user  services  result. 

The  database  administrator  should  interpret  and  administer 
upper  level  management  policies  as  they  are  related  to  the  database,  and 
define  rules  of  use  and  access  constraints  for  the  database.  Addition¬ 
ally,  the  DBA  should  be  held  accountable  for  review  and  approval  of  new 
data  definitions  and  the  enforcement  of  data  standards.  These  enforce¬ 
ment  activities  include:  determination  of  compliance  with  established 
standard  usages;  development  of  database  content,  organization  and  storage 
control  procedures;  and,  responsibility  for  access  control  and  security 
of  the  database  as  previously  mentioned. 

c.  Benefits  of  the  Database  Administrator 

Adoption  and  utilization  of  database  administrator  concepts 
as  vested  in  the  database  administrator  dramatically  improve  the  effec¬ 
tive  ness  of  an  organization's  data  processing  efforts  since  a  focal 
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point  is  firmly  established  for  the  responsibility,  management,  and 
control  of  total  data  resources.  Some  of  the  major  advantages  to  upper 
management  of  having  a  positive  database  administration  function,  as 
implemented  by  a  strong  database  administrator  follow. 

The  controlled  database  environment  that  is  managed  by  the 
database  administrator  helps  to  assure  efficient  performance  and  increased 
operational  reliability  in  the  manipulation  of  data.  This  can  promote 
data  integrity,  encourage  standard  data  usages,  enforce  security  safe¬ 
guards,  ensure  controlled  accessibility,  and  balance  conflicting  require¬ 
ments.  Application  of  the  multiple  tools  that  are  part  of  the  database 
administrator ' s  tool  chest  can  improve  the  utilization  of  the  database. 

The  uniform  database  monitoring  that  is  accomplished  by  the 
database  administrator  and  his  staff  can  facilitate  a  total  organizational 
overview  of  all  of  the  data  resources.  It  can  help  in  managing  the 
growth  and  changes  that  occur  in  the  database  by  ensuring  that  such  growth 
is  antipated  and  controlled.  The  optimization  of  database  utilization 
can  result  from  the  enforcement  of  shared  data  resources.  Any  required 
reorganization,  redesign,  and  restructuring  activities  associated  with 
the  database  can  be  performed  centrally  for  the  entire  organization 
simultaneously. 

3.  Personnel  Reorganization 

Since  database  administration  is  primarily  a  human  function,  its 
influence  is  affected  by  its  placement  within  the  organizational  hier¬ 
archy.  The  variety  of  opinions  with  respect  to  the  optimal  residence 
of  a  DBA  leads  one  to  conclude  that  there  is  really  no  perfect  organiza¬ 
tional  placement  for  a  database  administrator.  Each  systenTs  environment 
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operates  with  distinct  organizational  character!' sties  and  the  decision 
as  to  where  to  place  the  DBA  nearly  always  involves  tradeoffs. 

Three  organizational  entities  with  which  the  DBA  must  contend 
are:  computer  operations,  which  is  concerned  with  operating  equipment; 
computer  system  analysis,  which  is  concerned  with  the  analysis  and 
design  of  user  applications;  and,  the  users,  who  are  concerned  with 
ease  of  access  to,  and  completeness  of,  the  database.  Personnel  in  each 
of  these  areas  primarily  consider  their  own  interests  and  make  the 
placement  of  the  D8A  within  any  of  these  organizational  units  a  question¬ 
able  policy.  The  solution  offered  is  to  place  the  database  administrator 
in  a  staff  position,  reporting  directly  to  the  highest  manager  responsible 
for  data  processing  within  the  organization. 

The  organization  of  the  Data  Processing  Office  at  Mare  Island 
Naval  Shipyard  indicates  a  logical  location  for  the  placement  of  the 
DBA  within  that  hierarchy.  Inserting  the  title  of  "Database  Administra¬ 
tion  Division"  and  a  functional  code  of  114,  the  DBA  will  acquire  the 
appropriate  organizational  niche.  The  pay  grade  of  the  data  base  admin¬ 
istrator  himself  should  be  equal  to  that  of  the  Operation  Division  Head, 
GS-12  (Government  Standard  level  twelve).  Staffing  of  the  Database 
Administration  Division  is  accomplished  by  employing  two  GS-9s  and  four 
GS-7s  as  heads  and  staff  members  of  the  "Technical  Branch"  (Code  114.1) 
and  "Administrative  Branch"  (Code  114.2)  respectively.  The  recommended 
reorganization  of  Mare  Island's  Data  Processing  Office  is  summarized  in 
figure  20. 

The  keypunch  unit  currently  employs  two  shift  supervisors,  GS-6, 
three  team  leaders,  GS-5,  and  twenty-three  data  transcribers,  GS-3/4, 
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These  personnel  are  distributed  roughly  evenly  between  the  daytime  and 
swing-shift  operating  periods.  With  the  implementation  of  the  automated 
inputs  associated  with  distributed  processing,  the  following  reorganiza¬ 
tion  of  these  personnel  would  occur:  both  supervisors  and  one  leader 
would  become  computer  operators  or  technicians,  one  per  snift;  and, 
seventeen  data  transcribers  would  be  transferred  to  the  distributed  data 
processing  sites  and  retitled  "Data  Input  Technician”,  thus  eliminating 
the  need  for  the  distributed  processing  sites  to  provide  an  individual 
dedicated  solely  to  keyboard  operations.  The  remaining  six  data  trans¬ 
cribers  and  two  leaders  would  retain  their  present  capacities  since  some 
keypunch  requirements  would  undoubtedly  remain.  No  other  reorganization 
of  the  Data  Processing  Office  is  needed  since  the  requirements  and 
functions  of  the  overall  Shipyard  Management  Information  System  would  not 
change  under  a  DDP  configuration. 

F.  DATA  BASE  MANAGEMENT  SYSTEM 

The  responsibility  of  defining  the  content  and  structure  of  the  data 
base  and  assigning  data  access  and  modification  rights  belongs  to  the 
database  administrator.  The  data  base  management  system  (DBMS)  is  that 
element  within  the  tool  chest  of  the  DBA  that  provides  an  integrated 
source  of  data  for  multiple  users,  while  presenting  different  views  of 
the  data  to  different  users.  It  can  be  characterized  as  generalized 
software  which  provides  a  single  flexible  facility  for  accommodating 
different  data  files  and  operations,  while  demanding  less  programming 
effort  than  conventional  programming  languages.  Since  the  general  orien¬ 
tation  of  this  chapter  has  been  toward  maintaining  compatibility  with 
the  Honeywell  6060  Information  System  currently  in  use  at  the  Mare  Island 
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Naval  Shipyard,  the  Honeywell  Integrated  Data  Store/II  (IDS/II)  data 
base  management  system  will  be  described  as  the  system  of  preference  for 
employment  in  the  distributed  data  processing  system. 

1 .  IDS/II  Description 

Honeywell's  IDS/II  is  a  generalized  database  management  system 
which  operates  on  the  CALL  level,  with  programs  written  in  COBAL-74, 
and  permits  users  to  create,  maintain  and  retrieve  data  [25].  On-line 
users  interact  with  IDS/II  through  an  interactive  language  which  pro- 
vides  a  wide  variety  of  data  manipulation  verbs.  IDS/II  will  run  on  the 
Honeywell  Series  6000  Information  System,  of  which  MINSY’s  6060  is  a 
member,  as  modified  by  an  extended  instruction  set.  Minimum  main  storage 
for  IDS/II  is  128K  words,  which  includes  the  storage  requirements  for  the 
GCOS  operating  system. 

IDS/II  employs  a  linked  list  using  both  forward  and  backward 
pointers  and  hierarchically  structured  files  consisting  of  fixed  and 
variable  length  records.  When  declaring  the  data  base,  users  may 
specify  that  it  be  logically  constructed  as  network,  hierarchical,  chained 
or  a  combination  of  these.  The  physical  organization  may  be  sequential, 
indexed-sequential  (ISAM),  or  random.  IDS/II  maintains  this  separate 
physical  and  logical  view  of  the  data  structures  to  allow  record  and  data 
placement  on  the  storage  media  to  be  essentially  independent  of  the  asso¬ 
ciations  and  relationships  among  those  records.  Facilities  are  provided 
for  storing  and  locating  records  directly,  through  a  key  field  embedded 
in  each  record,  or  relatively  through  its  current  location  in  its  chain. 
Both  hierarchical  and  network  data  structures  are  supported  as  a  by-product 
of  the  record  linking  and  chaining  techniques. 
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A  high-level  of  data  security  is  offered  by  IDS/ 1 1  which  allows 
users  to  assign  passwords  down  to  the  field  level.  Data  integrity  is 
also  to  the  field  level  which  enables  changes  to  be  made  to  the  data 
base  without  recompiling  the  applications  that  may  employ  them.  Fur¬ 
ther  data  integrity  is  enhanced  through  systems  journalization,  automatic 
restart,  and  automatic  recovery  capabilities. 

2,  Data  Base  Structure 

An  Integrated  Data  Store/I  I  data  base  is  described  in  terms  of 
three  main  types  of  entities:  a  schema  (global)  definition  of  all  data 
structures  in  the  data  base,  their  logical  associations  and  interrela¬ 
tions,  and  their  primary  storage  and  retrieval  attributes;  one  or  more 
subschemas  or  definitions  of  subsets  of  the  schema  that  are  accessible 
by  application  programs;  and,  area  definitions  that  describe  the  maoping 
of  the  schema  and  subschema  data  structures  to  physical  data  sets.  At 
the  elemental  data  levels,  an  IDS/ 1 1  data  base  comprises  records  and 
sets.  A  record  is  a  named  collection  of  data  items  indicating  both  the 
primary  access  method  through  which  record  storage  and  retrieval  will  be 
done,  and  the  record  occurrence  to  area  mapping  attributes.  A  set  is  a 
named  collection  of  records  which  have  a  logical  relationship.  One 
record-type  is  defined  as  a  set  OWNER,  while  a  second  record-type  is 
defined  as  a  set  MEMBER.  Set  relationships  can  be  built  to  form  hier¬ 
archies,  simple  and  complex  networks,  and  cycles.  Structural  linkages  of 
set  members  can  be  used  to  provide  secondary  access  paths  to  records. 

Primary  access  paths  to  a  given  record  are  a  function  of  its 
LOCATION  MODE,  the  method  by  which  it  is  entered  onto  the  data  base. 
Records  are  first  stored  in  and  retrieved  from  a  data  file,  each  record 
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is  then  assigned  a  unique  data  base  key  wnich  represents  its  storage 
location  relative  to  the  start  of  the  data  base.  Each  record  defined 
for  the  schema  must  describe  its  location  mode  by  either  a  DIRECT,  CALC, 
or  VIA  set-name.  Records  defined  as  having  a  DIRECT  location  rede  are 
assigned  a  data  base  key  by  either  the  Data  3ase  Control  System  (DBCS) 
or  the  user.  The  user  to  DBCS  interface  is  through  a  parameter  in  a  user 
work  area.  CALC  location  mode  records  are  located  by  virtue  of  a  trans¬ 
form  algorithm  that  uses  values  contained  in  specified  data  fields  of  a 
record  to  produce  a  header  address,  VIA  set-name  location  mode  records 
are  stored  as  close  as  possible  to  their  owner  record  within  the  data 
base. 

3.  Data  Description 

Data  description  is  effected  through  three  media:  schema  and 
subschema  Data  Definition  Languages  (DDL)  and  a  Device  Media  Control 
Language  (DMCL).  The  schema  DDL  describes  data  base  content  such  as 
physical  record  structure,  access  methods,  privacy  constraints,  data 
items  and  their  attributes,  and  set  relationships;  the  schema  thus 
defines  the  global  data  base.  The  subschma  DDL  defines  subsets  of 
this  global  data  base  and  provides  the  user  interface  with  the  schema. 

The  DMCL  describes  the  storage  space  areas  and  their  page  sizes.  Each 
of  these  is  to  be  controlled,  maintained,  and  implemented  by  the  database 
administrator. 

The  DBA  implements  each  of  these  elements  separately  from  any 
intended  using  program.  The  schema  is  developed  first  graphically,  then 
translated  into  a  series  of  global  DDL  statements,  compiled,  and  entered 
into  a  data  element  dictionary  and  schema  file.  A  similar  sequence  is 


164 


followed  for  the  DMCL.  Subschemas  are  developed  for  the  using  programs, 
compiled,  validated  against  the  schema,  and  entered  into  a  validated 
subschema  file.  Associated  with  all  definitions  (schema,  subschema,  and 
area)  are  orivacy  locks  which  can  be  further  strengthened  through  pass¬ 
word  controls  established  at  the  general  comprehensive  operating  system 
and  file  maintenance  supervisor  levels. 

4.  Data  Retrieval 

Data  accessing  is  through  a  subschema  declarative  that  is  incor- 

« 

porated  into  the  data  division  of  a  using  program's  COBOL-74  source  deck. 
During  compilation,  a  user  work  area  is  created  and  the  subschema  linkage 
data  is  compiled  into  object  code.  At  execution  time,  a  check  is  made  to 
determine  if  the  proper  subschema  has  been  compiled,  validated,  and  trans¬ 
lated  in  logical  sequence.  The  using  program  is  then  linked  with  the 
subschema  object  file,  and  necessary  control  references  are  provided. 
During  processing,  data  pages  are  read  into  internal  buffer  regions, 
which  may  be  either  pooled  or  distributed  on  an  area  basis.  The  subschema 
may  declare  that  the  data  items  of  any  record  format  be  ordered  in  a 
fashion  convenient  to  the  using  program.  The  data  content  itself  may 
be  transformed  to  a  format  convenient  to  the  using  program  through  ENCODE 
and  DECODE  functions.  A  full  word  of  binary  data  within  the  data  base 
will  thus  be  represented  to  various  using  programs  as  packed  decimal  or 
ASCII  character  string  data. 

Communication  between  the  using  program  and  the  Data  Base  Control 
System  (OBCS)  is  accomplished  through  various  registers  and  flags,  and 
through  the  system's  Data  Manipulation  Language  (DML).  At  any  point 
during  processing,  the  user  is  able  to  receive  the  current  status  of  all 
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database  functions  relative  to  the  program.  He  will  know  which  area  is 
current,  which  set  and  record  name  is  current,  and  the  status  of  a 
requested  DML  function.  Data  base  keys  are  related  tnrough  comunica- 
tions  registers  and  privacy  locks  supplied  to  the  D8CS  through  a  defined 
register.  Privacy  locks  may  be  declared  to  disallow  access  to  a  record, 
or  to  disallow  specific  DML  functions  for  a  subschema  unless  the  lock's 
key  is  supplied.  Records  may  be  retrieved,  stored,  inserted,  removed 
or  erased  from  a  set  if  the  proper  privacy  locks  have  been  cleared. 

A  FIND  is  included  in  the  data  maniDulation  language  which  per¬ 
mits  record-sel ecti on  expressions  based  on  structural  conditions  exist¬ 
ing  in  the  data  base  such  as  find  next-in-path,  and  find  record-name 
within  a  set  or  area.  Other  IDS/ r I  interactive  data  manipulation  verbs 
include:  ACCEPT,  CONNECT,  DISCONNECT,  ERASE,  FINISH,  GET,  LIST,  MODIFY, 
MOVE,  READY,  REPEAT,  SET,  STORE,  and  USE.  The  ACCEPT  and  SET  verbs  pro¬ 
vide  data  base  key  manipulations,  FINISH  and  READY  provide  area  prepara¬ 
tion  statements.  USE  invokes  any  embedded  data  procedures  in  DBCS  required 
for  a  current  operation.  The  remainder  of  the  verbs  perform  record  and 
data  manipulative  functions.  Boolean,  comparative,  or  relational  opera¬ 
tions  must  be  performed  through  host  facilities  of  COBOL-74. 

G.  EQUIPMENT  ORGANIZATION 

Previous  portions  of  this  chapter  have  delineated  problems  associated 
with  the  current  Shipyard  Management  Information  System  as  it  is  employed 
at  Mare  Island  Naval  Shipyard,  Compatibilities  which  exist  between  dis¬ 
tributed  data  processing  and  MIS  philosophies  have  been  described  which 
have  led  to  the  implication  that  DDP  fulfills  MIS  managerial  requirements. 
The  need  for,  and  benefits  of,  a  database  administrator  to  be  responsible 
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for  the  management  of  the  data  base  have  also  been  presented.  "The  method 
by  which  personnel  of  the  Data  Processing  Office  will  be  prepared  for 
the  new  processing  procedure  and  the  relatively  minor  reorganization 
necessary  within  this  office  have  also  been  related.  For  sake  of  brevity, 
it  has  been  assumed  that  permission  has  been  received  to  implement  dis¬ 
tributed  data  processing  and  to  acquire  DDP  equipment  that  is  compatible 
with  the  Honeywell  6060  information  system.  What  remains,  then,  is  to 
describe  the  equipment  organization  that  will  be  required  to  construct 
a  distributed  data  processing  system  at  Mare  Island  Naval  Shipyard. 

1 .  Network  Configuration 

There  are  three  commonly  used  methods  of  distributing  the  data 
base  to  satisfy  the  requirements  of  a  distributed  management  informa¬ 
tion  system  [26],  These  processing  configurations  are  known  as  star, 
hierarchical ,  and  ring  networking.  Each  of  these  methods  has  inherent 
advantages  and  disadvantages.  However,  since  this  analysis  is  tasked 
with  retaining  the  6060  system  as  a  basis  for  distributed  extensions, 
the  overall  network  configuration  to  be  implemented  is  also  constrained 
by  this  requirement. 

a.  Hierarchical  Configuration 

The  hierarchical  configuration  is  a  viable  means  of  implement¬ 
ing  the  data  base.  Within  this  configuration,  the  system  consists  of  a 
host  computer  followed  by  an  arrangement  of  lesser  machines  until  a  ter¬ 
minal  level  is  rached.  The  primary  advantage  of  a  hierarchical  config¬ 
uration  is  that  it  provides  distributed  computing  power.  This 
configuration  is  also  quite  suitable  for  implementing  heterogeneous  nodal 
processing  systems.  Although  there  are  no  inherently  obvious  major 


167 


disadvantages  to  this  configuration  technique,  one  characteristic  elimin¬ 
ates  it  from  further  consideration:  since  a  desired  theme  is  system 
homogeneity  and  standardization,  and  since  heterogeneous  nodes  require 
additional  translation  processes  to  make  them  interact  smoothly  with  the 
overall  system,  this  becomes  a  future  development  for  MINSY  and  not  to 
be  considered  here. 

b.  Ring  Configuration 

A  ring  configuration  is  the  ideal  of  the  distributed  proces¬ 
sing  purist.  All  data  is  distributed;  no  redundant  data  exists;  and, 
nodes  share  data  through  a  common  link.  Ring  configuration  provides 
autonomous  processing  nodes  without  redundant  data,  which  is  ideal  as 
long  as  the  system  remains  sound.  Tf  a  break  occurs  in  the  ring,  no 
backup  is  available  unless  a  redundant  ring  is  installed,  resulting  in 
demise  of  the  entire  system,  especially  if  the  failed  node  holds  an 
important  portion  of  the  data  base.  The  DBA  must  devise  an  updatable 
directory  to  identify  where  specific  information  is  located  around  the 
ring  and  then  place  it  where  it  is  accessible  to  all  nodes.  A  solution 
to  both  problems  is  to  cornect  the  processing  nodes  to  a  central  host 
which  could  contain  both  the  directory  and  the  backup  data  base.  This 
leads  to  the  configuration  of  choice,  the  star  configuration. 

c.  Star  Configuration 

The  star  configuration  is  similar  to  the  commonly  used 
centralized  data  base  concept.  This  system  consists  of:  a  host  computer 
that  contains  a  central  data  base,  controllers,  and  the  common  data 
access  method;  and,  node  processors  consisting  of  minicomputers  and 
relevant  portions  of  the  distributed  data  base.  This  centralized  system 
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provides  tight  control  over  data,  ensures  data  security,  provides  a  common 
file  accessing  technique,  and  provides  a  common  data  base  logical  struc¬ 
ture  . 

A  major  problem  associated  with  this  configuration  is  data  unavail¬ 
ability  due  to  file  usage  or  line  loading.  A  way  of  overcoming  this  is  to 
distribute  copies  of  the  appropriate  data  to  the  concerned  processing 
nodes  thus  eliminating  delays  due  to  line  loading  or  use  by  other  nodes. 
This  does  result  in  data  redundancy  and  some  loss  of  control  in  terms 
of  directory  maintenance,  however,  the  benefits  of  backup  and  share- 
ability  offset  those  disadvantages.  By  retaining  a  master  copy  of  the 
data  base  locally,  the  database  administrator  is  able  to  exercise  control 
over  its  content,  organization,  and  security.  Redundancy  enhances 
backup  and  shareability  since  the  central  system  is  able  to  continue 
servicing  other  nodes  requiring  data  from  a  failed  node. 

If  the  failure  of  a  node  is  due  only  to  a  communications  break¬ 
down,  the  node  will  continue  to  service  local  users.  This  continued 
processing  does  compromise  the  integrity  of  the  data  at  the  central  site 
which  is  only  as  current  as  the  last  input  from  the  nodes.  A  highly 
dynamic  MIS  cannot  tolerate  a  prolonged  nodal  failure.  A  solution  is  to 
permit  normal  processing  to  be  on  a  query-only  basis,  where  not  all  data 
would  be  as  current  as  possible,  with  all  updating  done  during  off-hours. 
Since  batch  processing  is  currently  handled  this  way  at  MINSY,  no  major 
changes  in  operating  procedures  would  be  required  to  implement  this 
technique. 

2.  Honeywell  Level-6  Minicomputer 

A  primary  ingredient  for  distributed  processing,  alluded  to 


throughout  this  presentation,  is  the  implementation  of  computing  power 
and  data  storage  for  a  specific  application  within  the  Shipyard  MIS  at 
a  dedicated  processing  node.  This  node  must  be  able  to  interface  with 
the  host  Honeywell  6060  system  through  the  installed  DATANET  355  Front- 
End  Network  Processor.  The  Honeywell  Level-6  Minicomputer  family  is 
suited  to  fulfill  those  requirements.  Level -6  architecture  is  based  on 
a  twenty-four-bit-wide  universal  bus  called  the  Megabus.  The  CPU  attaches 
directly  to  the  Megabus  using  controller  boards,  which  give  Level-6  a 
modular  architecture.  Up  to  four  device  or  memory  pacs,  a  Honeywell  term 
for  dedicated  modules,  fit  on  one  controller  board.  Since  the  memory  and 
peripherals  are  attached  to  the  sane  bus,  all  data  is  transferred  using 
direct  memory  access  [27]. 

a.  Central  Processor 

All  Level -6  processors  use  a  microprogrammed  architecture 
with  a  transistor-to-transistor  bipolar  logic  (TTL)  and  a  sixteen  bit 
word  length.  Standard  features  for  Level-6  processors  include  sixty-four 
firmware-controlled  vectored  priority  interrupts,  extended  instruction 
sets,  flexible  word  lengths,  hardware  multiply  and  divide,  a  real-time 
clock,  a  ROM-based  boostrap  loader,  and  ROM-based  diagnostics. 

Most  hardware  registers  are  sixteen  bits  in  length  except  for 
the  mode  registers  which  are  eight  bits  long.  Within  this  framework, 
the  CPU  can  process  double  words  (thirty-two  bits),  words  (sixteen  bits), 
bytes  (eight  bits)  or  single  bits.  Floating  point  values  can  be  two  or 
four  words.  The  Level -6  uses  two  types  of  data:  signed  data  is  used  in 
arithmetic  operations;  unsigned  data  is  ued  for  logical  quantities,  addres¬ 
ses,  or  ASCII  characters.  Unsigned  data  is  expressed  in  hexadecimal 
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notation  while  signed  data  is  represented  in  two's  complement  notation. 

The  basic  set  of  106  instructions  include:  bit  instructions 
for  testing,  resetting,  and  complementing  addressed  bits;  byte  instruc¬ 
tions  for  logical  arithmetic  operations;  and  word  and  multiple  word 
instructions  for  handling  data  of  variable  size.  Single  and  double¬ 
operand  instructions  manipulate  the  data  in  registers  and  memory; 
short-value  immediate  instructions  manipulate  data  in  the  general  regi¬ 
sters.  There  are  thirty-two  branch  and  branch-on-indicator  instructions, 
twelve  shift  instructions,  three  I/O  instructions ,  and  fifteen  generic 
instructions. 

Sixty-four  multiple  vector  interrupt  levels  can  be  priority 
programmed  by  the  user  and  implemented  by  firmware  through  the  Megabus. 
Interrupt  levels  for  each  controller  can  be  dynamically  set  by  software 
before  each  job  or  before  each  peripheral  instruction  sequence.  The  CPU 
determines  from  the  assigned  interrupt  level  whether  a  board  can  inter¬ 
rupt,  and  the  order  in  which  interrupts  will  be  honored.  The  processor 
can  receive  an  interrupt  request  at  any  time,  including  the  time  between 
the  two  cycles  of  a  read  operation.  However,  the  interrupt  is  not  proces¬ 
sed  until  the  instruction  has  been  completed, 
b.  I/O  Control 

All  input  and  output  for  Level-6  minicomputers  occur  over  the 
Megabus  using  direct  memory  access  (DMA)  transfers.  The  Megabus  is  an 
asynchronous,  bidirectional  bus  with  a  transfer  rate  of  six  mega-bytes  per 
second  and  a  cycle  time  of  300  nanoseconds.  The  bus  is  fast  enough  to 
allow  many  I/O  operations  to  be  multiplexed.  Multiple  I/O  units  can  multi¬ 
plex  on  a  word  basis  to  the  same  memory  unit  as  long  as  the  combined  data 


transfer  rates  do  not  exceed  the  maximum  memory  transfer  rate  of  1 . 1 
million  words  per  second.  Three  intelligent  peripheral  controllers 
are  provided:  the  Multiple  Device  Controller,  Mass  Storage  Controller, 
and  Magnetic  Tape  Controller.  A  general -purpose  DMA  interface  for  user 
logic  is  also  present. 

c.  Peripherals 

Honeywell  supplies  a  broad  range  of  low-speed  peripherals 
and  high-speed  units  in  addition  to  a  number  of  terminals.  All  peri¬ 
pherals  interface  through  device  pacs  (modules)  on  the  individual  con¬ 
troller  boards  which  connect  to  the  Megabus.  Level-6's  low-speed  devices 
(card  readers)  card  punchers,  serial  and  line  printers)  are  supported 
by  the  Level-6  Operating  System  and  require  device  pacs  that  fit  on  the 
Multiple  Device  Controller.  High-speed  peripherals  are  also  supported 
by  the  Level -6  Operating  System;  magnetic  tape  drives  require  a  device 
pac  for  each  drive  and  one  magnetic  tape  controller  for  every  four  drives; 
up  to  four  large  disc  packs  are  supported  by  one  device  pac  and  one  Mass 
Storage  Controller.  Teletype-compatible  CRTs  and  teleprinters  are  sup¬ 
ported  by  the  GCOS-6  software  and  interface  to  the  Megabus  through  the 
Multiple  Device  Controller  or  through  the  Multiline  Communications  Proces¬ 
sor. 

d.  Data  Communications 

The  Multiline  Communications  Processor  (MLCP)  is  the  hard¬ 
ware  basis  to  Level-6  data  communication  capabilities.  The  MLCP  board 
has  a  microprocessor  with  3,072  words  of  RAM  that  the  user  can  program 
for  his  own  line  handling  and  protocols  with  the  help  of  MLCP  software. 

The  on-board  microprocessor  delimits  the  data  stream  and  offloads  the  CPU 
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of  character  generation,  error  detection,  and  the  clock-check  function. 
Maximum  throughput  is  twenty-four  thousand  bytes  per-second.  The  MLCP 
holds  up  to  four  line  adapters  of  any  mix  of  synchronous,  asynchronous , 
broadband,  or  current-loop  connection  communication  pacs. 

MLCP  software  is  supported  under  the  Honeywell  General  Com¬ 
prehensive  Operating  System.  GCOS-6  supports  synchronous  and  asynchro¬ 
nous  protocols,  and  communications  features  including  a  subset  of  the 
IBM  2780  bi-synchronous  protocol.  Two  communications  utilities  are 
available  under  GCOS-6:  Data  Entry  Facility  (DEF)  is  a  data-entry  forms 
package;  and,  Remote  Batch  Facility  ( R3F }  allows  the  Level-6  processor 
to  be  r.ed  as  a  remote  batch  station  for  the  host  processor, 
e.  Software 

Honeywell  provided  software  for  the  family  of  Level -6  mini¬ 
computers  includes  operating  systems,  language  processors  and  a  wide 
range  of  utilities.  The  GCOS-6  operating  systems  are  multi-tasking, 
multi-user  disk-based  operating  systems.  Source  and  object  text  programs 
of  the  Basic  Executive  System  (BES)  can  be  run  under  GCOS-6.  Five  major 
languages  are  available  for  the  Level-6:  assembler  with  macro  preproces¬ 
sor,  FORTRAN,  COBOL,  BASIC,  and  RPG.  GCOS-6  and  BES  operating  systems 
utilities  include  the  options  of  Sort/Merge,  DEF,  and  RBF. 

Cl)  Operating  System.  As  a  full  diskette-based  real-time 

software  system,  GCOS-6  has  extensive  executive,  file  management,  and 
communications  facilities,  and  a  wide  complement  of  development  software. 
The  GCOS-6  executive  concurrently  executes  one  batch  stream  (program 
development  or  other  user  application)  and  a  number  of  on-line  user 
application  job  steams  limited  only  by  the  amount  of  available  memory. 
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Batch  applications  can  be  rolled  out  to  a  mass  storage  device  in  order 
to  obtain  more  memory  for  on-line  applications. 

Operators  communicate  with  the  operating  system  through 
four  control  languages:  System  Generation,  Execution  Control,  Operator 
Control,  and  Monitor  Control.  The  System  Generation  Language  is  used 
to  develop  system  generation  directives  from  a  set  of  directives  supplied 
with  the  operating  system.  The  Execution  Control  Language  controls  all 
task  groups,  enables  users  to  submit  batch  requests,  handles  file-related 
functions,  and  handles  the  execution  of  all  utilities.  The  Operator 
Control  Language  allows  the  operator  to  control  on-line  task  groups, 
batch  streams,  and  device  assignment.  Macro  calls  of  the  Monitor  Control 
Language  allow  the  user  to  perform  monitor  functions  with  an  assembler 
language  program. 

The  GCOS-6  tree-structured  file  system  provides  different 
file  systems  for  each  of  the  supported  I/O  devices.  It  provides  four 
file  organizations  for  discs  -  sequential,  relative,  indexed,  and  fixed- 
relative.  Sequential  access  is  provided  for  magnetic  tape,  communica¬ 
tions,  and  all  unit  record  devices.  Files  can  be  accessed  by  COBOL, 
FORTRAN,  RPG,  or  assembler  language  statements.  GCOS-6  requires  a  CPU 
with  thirty-two  thousand  words  of  memory,  one  cartridge  disk  unit,  or 
four  diskettes,  and  one  terminal. 

(2)  Language  Processor,  GCOS-6  (entry  level)  COBOL  is  based 
on  ANSI  COBOL-74  standards.  This  COBOL  level  requires  thirty-two  thou¬ 
sand  words  of  memory.  Extensions  include  support  of  file  handling  for 
sequential,  relative,  and  indexed  files,  three-dimensional  tables,  CALL 
and  CANCEL  capability,  DISPLAY  and  COMPARE  data,  full  American  National 
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Standard  editing,  and  twenty-one  additional  verbs.  GCOS-6  (intermediate' 
COBOL,  also  based  on  ANSI  COBOL-74  standards,  provides  facilities  for 
reentrant  programs,  packed  decimal  and  thi rty-two-bi t  signed  binary  data 
types,  and  the  callable  Sort/Merge  utility.  Even  though  other  languages 
are  supported  by  GCOS-6,  only  the  COBOL  language  has  been  further  ampli¬ 
fied  since  that  is  the  language  of  use  at  Mare  Island's  Data  Processing 
Center. 

(3)  Util ities.  The  Sort/Merge  utility  for  GCOS-6  features 
up  to  sixteen  sort-key  files  of  ASCII  or  numeric  data;  the  output  sequence 
is  based  on  ascending  or  descending  sequence  by  key:  a  temporary  work 
file  can  be  created  and  automatically  deleted  later;  the  BES  Sort 
accepts  control  fields  of  up  to  eight  keys  per  record  with  a  maximum  singl 
key  size  of  356  bytes  and  a  maximum  record  size  of  512  bytes.  The  Data 
Entry  Facility  of  the  GCOS-6  utility  for  form  creation  supports  up  to 
twelve  terminals  and  up  to  six  line  or  serial  printers;  the  DEF  package 
is  able  to  execute  simultaneously  with  the  GCOS  operating  system.  The 
Remote  Batch  utility  allows  the  Level -6  to  be  used  as  a  remote  batch  ter¬ 
minal  to  the  host  computer  while  still  performing  its  own  on-line  proces¬ 
sing;  the  host  computer  is  interfaced  by  Remote  Computer  Interface 
protocols. 

3.  DPP  System  Architecture 

The  architecture  of  the  distributed  data  base  system  at  Mare 
Island  Naval  Shipyard  must  closely  resemble  the  representative  DDP 
system  as  presented  earlier  in  figure  3,  of  chapter  I,  and  as  constrained 
by  the  6060  system  already  in  use.  The  Honeywell  6060  system  is  to  remain 
as  the  host  processor  and  contain  the  central  CPU.  The  central  data  base 
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remains  resident  within  MI  .VS  Y '  s  Data  Processing  Center.  The  Integrated 
Data  Store/I  I  database  management  system  is  to  be  incoroorated  into  the 
overall  system.  The  DATANET  355  Front-End  Network  Processor  provides 
a  controlling  function  for  the  Level-6  Minicomputers  that  are  to  be 
installed  as  node  processors.  Each  Level-6  site  contains  the  data  base 
and  full  rnage  of  peripherals  relevant  to  that  particular  subsystem  or 
application  mode  that  the  node  is  dedicated  to  serve.  Figure  21  por¬ 
trays  this  overall  system. 

Whether  or  not  a  location  that  is  a  candidate  site  for  a  distri¬ 
buted  node  receives  a  Level -6  Minicomputer  with  its  full  range  of  dedi¬ 
cated  databases,  input  and  query  permissions  as  well  as  peripherals,  a 
CRT  and  keyboard  for  query-only,  or  a  CRT  and  keyboard  including  input 
as  well  as  query  permissions,  is  dependent  upon:  its  relative  importance 
in  the  shipyard  organizational  hierarchy;  the  amount  of  information  it 
requires  to  efficiently  perform  its  function;  the  number  of  transactions 
it  generates;  and,  the  volume  of  data  that  is  inherent  to  its  functional 
application  within  the  Shipyard  MIS.  Initially,  the  following  six 
functional  areas  within  MINSY  should  contain  a  Level-6  Minicomputer  with 
its  full  range  of  databases,  input  and  query  permissions,  as  well  as 
peripherals:  the  Planning,  Production,  Supply,  Comptroller,  and  Admin¬ 
istrative  Departments,  and  the  Data  Processing  Office.  Offices  that  will 
be  allowed  query  and  input  functions  will  be  connected  to  the  relevant 
Level-6  application  they  serve.  Inputs  will  be  allowed  only  to  the  files 
for  which  a  specific  terminal  is  responsible.  Query-only  terminals  are 
to  be  connected  to  the  specific  Level -6  function  to  which  they  refer,  but 
may  access  the  central  data  base  and  other  nodes  for  information  that  is 
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required  in  the  performance  of  the  duties  of  the  area  in  which  they  are 
resident.  These  initial  connections  are  summarized  in  figure  22.  It 
will  be  the  responsibility  of  the  requesting  department  head  in  liaison 
with  the  Management  Engineering  Office  and  the  Database  Administrator 
to  decide  on  the  placement  of  Level-6  Minicomputers  and  terminals 
throughout  Mare  Island  Naval  Shipyard. 
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